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版 本 控制 是 管理 数据 变更 的 艺术 ， 无 论 数 据 变更 是 来 目 同 一 个 
人 ， 还 是 来 自 不 同 的 人 (一 个 团队 ) 。 版 本 控制 系统 不 但 要 写实 地 记 
录 数 据 的 每 一 次 变更 ， 还 要 能 够 帮助 还 原 任何 一 次 历史 变更 ， 以 及 实 
现 团队 的 协同 工作 等 。Git 殉 是 版 本 控制 系统 中 的 佼佼 者 。 


我 对 版 本 控制 系统 的 兴趣 源 自 于 我 的 个 人 知识 管理 实践 ， 其 核心 
就 是 撰写 可 维护 的 文档 ， 并 保存 于 版 本 控制 系统 中 。 可 维护 文档 的 格 
式 可 以 是 DocBook、FreeMind、reStructuredText 等 。 我 甚至 还 对 
FreeMind 加 以 改造 以 便 让 其 文档 格式 更 适合 于 版 本 控制 系统 ， 这 就 是 
我 的 第 一 个 开源 实践 : 托管 于 SourceForge 上 的 FreeMind-MMX 项 目 中 
。 文档 书写 格式 的 问题 解决 之 后 ， 就 是 文档 的 存储 问题 了 。 通 过 版 本 
控制 系统 ， 很 自然 地 就 可 以 实现 对 文档 历史 版 本 的 保存 ， 但 是 如 何 避 
免 因为 版 本 控制 系统 次 痪 而 导致 数据 丢失 呢 ? Git 用 其 革新 的 分 布 式 的 
版 本 控制 设计 提供 了 最 好 的 解决 方案 。 使 用 Git， 我 的 知识 库 不 再 只 
唯一 的 版 本 库 与 之 对 应 ， 而 是 可 以 通过 克隆 操作 分 发 到 不 同 的 磁盘 或 
主机 上 ， 殉 隆 的 版 本 库 之 间 通 过 推送 (PUSH) 和 拉 回 (PULL) 等 操 
作 进 行 同步 ， 数 据 安全 得 到 了 极 大 的 提升 。 在 版 本 控制 系统 的 忠实 阿 
护 下 ， 我 的 知识 库 中 关于 Git 的 FreeMind 脑 图 在 日 积 月 累 中 变 得 越 来 越 
翔实 ， 越 来 越 清 晰 ， 最 终 成 为 本 书 的 雏形 。 


版 本 控制 能 决定 项 目的 成 败 ， 甚 至 是 公司 的 生死 ， 此 言 不 虚 。 我 
在 推广 开源 项 目 管 理工 具 和 为 企业 提供 咨询 服务 的 过 程 中 看 到 ， 有 很 
多 团队 因为 版 本 控制 系统 管理 的 混乱 导致 项 目 延 期 、 修 正 的 Bug 重 
现 、 客 户 的 问题 不 能 在 代码 中 定位 ..…... 无 论 他 们 使 用 的 是 什么 版 本 控 
制 系统 (开源 的 或 是 商业 的 ， 都 是 如 此 。 这 是 因为 传统 的 集中 式 版 本 
控制 系统 不 能 有 效 地 管理 分 文 和 进行 分 文 间 合 并 。 集 中 管理 的 版 本 库 
只 有 唯一 的 分 文 命 名 空间 ， 需 要 专人 管理 ， 从 而 造成 分 文 创 建 的 不 目 
由 ; 分 文 间 的 合并 有 要么 因为 缺乏 追 踩 导 致 重复 合并 、 引 发 严重 钟 突 ， 
要 么 因为 版 本 控制 系统 本 身 鉴 脚 的 设计 导致 分 支 合 并 时 效率 低下 和 陷 
阱 重重 。Git 凭 借 其 灵活 的 设计 让 项 目 摆脱 分 支管 理 的 梦 厦 。 


我 的 公司 也 经 历 过 代码 管理 的 生死 考验 。 因 为 公司 的 开发 模式 主 
要 是 基于 开源 软件 的 二 次 开发 ， 所 以 最 早 在 使 用 SVN (Subversion) 做 
版 本 控制 时 ， 很 自然 地 使 用 了 SVN 卖 主 分 支 模 型 来 管理 代码 。 随 着 增 
加 和 修改 的 代码 越 来 越 多 ， 我 们 开发 的 软件 与 开源 软件 上 游 的 偏离 也 
越 来 越 远 ， 当 上 游 有 新 版 本 发 布 时 ， 最 早 可 能 只 用 几 个 小 时 束 可 以 将 
改动 迁移 过 去 ， 但 是 如 果 对 上 游 的 改动 多 达 几 十 甚至 上 百 处 时 ， 迁 移 
的 过 程 吏 会 异常 痛 杏 ， 基 本 上 和 重新 做 一 过 莽 不 多 。 那 时 似乎 只 有 一 
种 选择 : 不 再 与 上 游 合 并 ， 不 再 追踪 上 游 的 改动 ， 而 这 与 公司 的 价值 
观 “ 发 动 全 球 智 慧 为 客户 创造 价值 ” 相 违 痛 。 迷 荡 之 中 ， 分 布 式 版 本 控 
制 系 统 允 然而 至 ， 原 来 版 本 控制 还 可 以 这 么 做 。 


我 最 先 党 试 的 分 布 式 版 本 控制 系统 是 Hg (Mercurial) ， 当 发 现 Hg 
和 MQ (Hg 的 一 个 插件 ) 这 一 对 宝贝 儿 的 时 候 ， 我 如 获 至 宝 。 逐 渐 
地 ， 公 司 的 版 本 库 都 迁移 到 了 Hg 上 “。 但 随 着 新 的 开发 人 员 的 加 入 ， 问 
题 又 出 现 了 ， 一 个 人 使 用 Hg 和 MQ 很 好 ， 但 多 个 人 使 用 时 则 会 出 现 难 
以 协同 的 问题 。 于 是 我 们 大 胆 地 采用 了 Git， 并 在 实践 中 结合 Topgit 等 
工具 进行 代码 的 管理 。 再 一 次 ， 也 许 是 最 后 一 次 ， 我 们 的 代码 库 迁 移 
到 了 Git 。 


最 早 认识 分 布 式 版 本 控制 ， 源 目 于 我 们 看 到 了 众多 开源 项 目的 版 
本 控制 系统 大 迁移 ， 这 场 迁 移 还 在 进行 中 。 
MoinMoin 是 我 们 关注 的 一 个 开源 的 维基 软件 ，2006 年 ， 它 的 代码 


库 从 SVN 迁 移 到 了 Hg 。 


Mailman 同 样 是 我 们 关注 的 一 个 开源 邮件 列表 软件 。2007 年 ， 它 
的 代码 库 从 SVN 迁 移 到 了 Bazaar13l 。 


Linux 采 用 Git 作 为 版 本 控制 系统 (一 点 都 不 奇怪 ， 因 为 Git 束 是 
Linus Torvalds 开 发 的 ) 。 


Android 坪 目前 最 为 流行 的 开源 项 目 之 一 ， 因 为 潜在 市 场 巨大 ， 已 
经 吸引 了 越 来 越 多 的 开发 者 进入 这 个 市 场 ， 而 Android 束 是 用 Git 维 护 
Hy 


当 开源 软件 纷纷 倒 疝 分 布 式 版 本 控制 系统 大 旗 (尤其 是 Git) 的 时 
候 ， 很 多 商业 公司 也 在 行动 了 ， 尤 其 是 涉及 异地 团队 协同 和 Android 核 
心 代 码 定制 开发 的 公司 。 对 于 那些 因 保 守 而 不 敢 向 Git 靠 拢 的 公司 ， 
Git 也 可 以 派 上 用 场 ， 因 为 Git 可 以 与 现在 大 多 数 公 司 部 署 的 SVN 很 好 
地 协同 ， 即 公司 的 服务 器 是 SVN， 开 发 者 的 客户 端 则 使 用 Git。 相 信 随 
着 Git 的 普及 ， 以 及 公司 在 代码 管理 观念 上 的 改进 ， 会 有 更 多 的 公司 拥 
抱 Git 。 


本 书 的 组 织 


本 书 共 分 为 9 篇 ， 前 8 篇 古 正文 ， 一 共 41 草 ， 第 9 篇 是 附录 。 


第 1 篇 讲解 了 Git 的 相关 概念 ， 以 及 安装 和 配置 的 方法 ， 共 3 草 。 第 
1 章 介绍 了 版 本 控 制 的 历史 。 第 2 章 用 十 几 个 小 例子 介绍 了 Git 的 一 些 内 
亮 特性 ， 期 待 这 些 特性 能 够 让 你 爱 上 Git。 第 3 章 则 介绍 了 Git 在 三 种 主 
要 操作 系统 平台 上 的 安装 和 使 用 。 在 本 书 的 写作 过 程 中 ， 我 70% 的 时 
间 使 用 的 是 Debian Linux 操 作 系统 ，Linux 用 户 可 以 毫 无 障碍 地 完成 本 
书 列举 的 所 有 实践 操作 。 在 2010 年 年 底 ， 当 得 知 有 出 版 社 愿意 出 版 这 
本 书后 ， 我 同 妻 子 阿 巧 预 文 了 未 来 的 部 分 稿费 购买 了 我 的 第 一 台 
MacBook Pro， 于 是 本 书 就 有 了 较为 翔实 的 如 何在 Mac OS X 下 安装 和 
使 用 Git 的 内 容 ， 以 及 在 本 书 第 22 章 中 介绍 的 关于 Topgit 在 Mac OS X 上 
的 部 署 和 改进 相关 的 内 容 。 在 本 书 的 编辑 和 校对 过 程 中 因为 要 使 用 


Word 格 式 的 文稿 ， 所 以 本 书后 期 的 很 多 工作 是 在 运行 于 VirtualBox 下 
的 Windows 虚 拟 机 中 完成 的 ， 即 使 是 使 用 运行 于 资源 受 限 的 虚拟 机 中 
的 Cygwin,Git 依 然 完 美 地 完成 了 工作 。 


第 2 篇 和 第 3 篇 详细 讲解 了 Git 的 使 用 方法 ， 和 是 本 书 的 基础 和 核心 ， 
大 约 占 据 了 全 书 40% 的 篇 幅 。 这 两 骗 的 内 容 染 构 方 式 是 我 在 进行 SVN 
培训 时 整 已 经 形成 的 习惯 ， 即 以 “独到 ” 指 代 一 个 人 的 版 本 控制 所 要 讲 
述 的 知识 点 ， 以 “和 声 ” 指 代 团 队 版 本 控制 涉及 的 话题 。 在 第 2 篇 “Git 独 
码 ” 中 ， 本 书 将 Git 的 设计 原理 穿插 在 各 革 之 中 讲解 ， 因 为 唯 有 了 解 真 
相 (Git 原 理 ) ， 才 有 可 能 自由 (掌握 Git) 。 在 第 3 篇 “Git 和 声 * 中 ， 本 
书 讲解 了 团队 版 本 控制 必须 掌握 的 里 程 碑 和 分 支 等 概念 ， 以 及 如 何 解 
决 合并 中 巡 到 的 冲突 。 


第 4 篇 细致 地 讲解 了 Git 在 实际 工作 中 的 使 用 模式 。 除 了 传统 的 集 
中 式 和 分 布 式 使 用 模式 之 外 ， 第 22 章 还 介绍 了 Topgit 在 定制 开发 中 的 
应 用 ， 这 也 是 我 公司 在 使 用 Git 时 采用 的 最 主要 的 模式 。 这 一 章 还 讲解 
了 我 对 Topgit 所 做 的 部 分 改进 ， 相 关 的 具体 介绍 最 早出 现在 我 公司 的 
博客 上 4。 第 23~~25 章 介绍 了 多 版 本 库 协 同 的 不 同方 法 ， 其 中 第 25 章 
介绍 的 一 个 独辟蹊径 的 解决 方案 是 由 Android 项 目 引入 的 名 为 repo 的 工 
具 实 现 的 ， 我 对 其 进行 改造 后 可 以 让 这 个 工具 脱离 Gerrit 代 码 审核 服务 


是 ， 直 接 操 作 Git 服 务 器 。 第 26 章 介绍 了 gitrsvn 这 一 工具 ， 该 工具 不 但 


ye! N 


可 以 实现 从 SVN 版 本 库 到 Git 版 本 库 的 迁移 ， 还 可 以 实现 以 Git 作 为 客 


户 端 向 SVN 提 交 。 


第 5 篇 介绍 了 Git 服 务 器 的 架设 。 本 篇 是 全 书 最 早 开 始 撰 写 的 部 
分 ， 这 是 因为 我 给 客户 做 的 Git 培 训 讲义 的 相关 内 容 不够 详细 ， 于 十 应 
客户 要 求 针 对 Gitolite 等 服务 句 的 染 设 撰写 了 详细 的 管理 员 手 册 ， 即 本 
书 的 第 30 章 。 第 32 章 介绍 了 Android 项 目 在 Git 管 理 上 的 又 一 大 创造 ， 
即 Gerit， 它 实现 了 一 个 独特 的 集中 式 Git 版 本 库 管 理 模型 。 


第 6 篇 讲解 了 Git 版 本 库 的 迁移 。 其 中 第 34 章 详细 介绍 了 从 CVS 版 
本 库 到 Git 版 本 库 的 迁移 ， 其 迁移 过 程 也 可 以 作为 从 CVS 到 SVN 迁 移 的 
彰 鉴 。 本 篇 还 介绍 了 从 SVN 和 Hg 版 本 库 到 Git 的 迁移 。 对 于 其 他 类 型 的 
版 本 库 ， 介 绍 了 一 个 通用 的 需要 编程 来 实现 的 方法 。 在 本 篇 的 最 后 还 
介绍 了 一 个 Git 版 本 库 整 理 的 利 左 ， 可 以 理解 为 一 个 Git 库 转换 为 另外 
一 个 Git 库 的 方法 。 


第 7 篇 是 关于 Git 的 其 他 应 用 ， 其 主要 内 容 介 绍 了 我 在 etckeeper 启 
发 下 开发 的 一 款 备 份 工具 Gistore， 该 工具 可 以 运行 于 Linux 和 Mac OS 
又 下 。 


8 篇 是 Git 洒 谈 。 其 中 第 40 章 的 内 容 可 供 跨 平台 的 项 目 组 借鉴 。 
第 41 章 介绍 了 一 些 在 前 面 没 有 涉及 的 Git 的 相关 功能 和 特性 。 


避 


第 9 篇 是 附 孙 。 首 先 介绍 了 完整 的 Git 命 令 索引 ， 然 后 分 别 介绍 了 
CVS、SVN、Hg 与 Git 之 间 的 比较 和 命令 对 照 ， 对 于 有 其 他 版 本 控制 系 
统 使 用 经 验 的 用 户 而 言 ， 这 一 部 分 内 容 颇 具 参 考 价值 。 


[1| http://freemind-mmx.sourceforge.net/ 
[2| http://moinmo.in/NewVCS 

[3] http://wiki.list.org/display/DEV/Home 
[4] http://blog.ossxp.com/ 


适用 读 震 


本 书 适 合 所 有 翻 开 它 的 人 ， 因 为 我 知道 这 本 书 在 书店 里 一 定 是 放 
在 计算 机 图 书 专柜 。 本 书 尤其 适合 以 下 几 类 读者 阅读 。 


1. 被 数据 同步 困扰 的 “电脑 人 ” 


困扰 “电脑 人 ”的 一 个 彰 见 问题 是 ， 有 太 多 的 数据 需要 长 久保 存 ， 
有 太 多 的 电脑 设备 需要 数据 同步 。 可 能 有 的 人 会 说 : “ 像 Dropbox 一 样 
的 网 盘 可 以 帮助 我 呀 ”。 是 的 ， 云 存储 就 是 在 撤 术 逐渐 成 熟 之 后 应 运 而 
生 的 产品 ， 但 是 依然 解决 不 了 如 下 几 个 问题 : 多 个 设备 上 同时 修改 造 
成 的 冲突 ;元 余数 据 传 输 造 成 的 市 宽 上 瓶颈; 没有 实现 真正 的 、 完 全 的 
历史 变更 数据 备份 。 具 体 请 参见 本 书 第 7 篇 第 39 草 的 内 容 。 


Git 可 以 在 数据 同步 方面 做 得 更 好 ， 甚 至 只 需 借助 小 小 的 U 表 束 可 
以 实现 多 台电 脑 的 数据 同步 ， 并 且 支 持 目 动 的 冲突 解决 。 只 要 阅读 本 
书 第 1 篇 和 第 2 篇 ， 束 能 轻易 掌握 相关 的 操作 ， 实 现 数据 的 版 本 控制 和 
同步 。 


2. 学 习 计 算 机 课程 的 学 生 


我 非常 后 悔 没有 在 学 习 编 程 的 第 一 天 号 开始 使 用 版 本 控制 ， 在 学 
校 时 写 的 很 多 小 程序 和 函数 库 都 丢失 了 。 直 到 使 用 了 CVS 和 SVN 对 个 


人 数据 进行 版 本 控制 之 后 ， 才 开始 把 每 一 天 的 变更 历史 都 保留 了 下 
来 。Git 在 这 方面 可 以 比 CVS 和 SVN 等 做 得 更 好 。 


在 阅读 完 本 书 的 前 3 篇 掌握 了 Git 的 基础 知识 之 后 ， 可 以 阅读 第 5 篇 
第 33 草 的 内 容 ， 通 过 Githubp 或 类 似 的 服务 提供 商 建立 目 己 的 版 本 库 托 
管 ， 为 目 己 的 数据 找 一 个 安全 的 家 。 


3. 程 序 员 


使 用 Git 会 让 程序 员 有 更 多 的 时 间 休 息 ， 因 为 可 以 更 快 地 完成 工 
作 。 分 布 式 版 本 控制 让 每 一 个 程序 员 都 能 在 本 地 拥有 一 个 完整 的 版 本 
库 ， 所 以 几乎 所 有 操作 都 能 够 脱离 网 络 执行 而 不 受 市 宽 的 限制 。 加 之 
使 用 了 智能 协议 ， 版 本 库 间 的 同步 不 但 减少 了 数据 传输 量 ， 还 能 显示 
完成 进 


O 


站 


Git 帮 助 程序 员 打 开 了 进入 开源 世界 的 大 门 ， 进 而 开阔 视野 ， 提 升 
水 平 ， 增 加 择业 的 夸 码 。 看 看 使 用 Git 作 为 版 本 控制 的 开源 软件 吧 : 
Linux kernel、Android、Debian、Fedora、GNOME、KDevelop、 
jQuery、Prototype、PostgreSQL、Ruby on Rails..…. 不 胜 枚 举 。 还 有 ， 
不 要 起 了 所 有 的 SVN 版 本 库 都 可 以 通过 Git 方 式 更 好 地 访问 。 


作为 一 个 程序 员 ， 必 须 具 备 团 队 协 同 能 力 ， 本 书 第 3 篇 应 该 作为 学 
习 的 重点 。 


4.Android 程 序 员 


如 果 你 是 谷歌 Android 项 目的 参与 者 ， 尤 其 是 驱动 开发 和 核心 开发 
的 参与 者 ， 必 然 会 接触 Git、repo 和 Gerrit。 对 于 只 是 偶尔 参考 一 下 
Android 核 心 代码 的 Android 应 用 开发 人 员 而 言 ， 也 需要 对 repo 有 深入 的 
理解 ， 这 样 才 不 至 于 每 次 为 同步 代码 而 耗费 一 天 的 时 间 。 


repo 是 Android 为 了 解决 Git 多 版 本 库 管 理 问 题 而 设计 的 工具 ， 在 本 
书 第 4 篇 第 25 章 有 详细 介绍 。 


Gerrit 是 谷歌 为 了 避免 因 分 布 式 开发 造成 项 目 分 裂 而 开发 的 工具 ， 
打造 了 Android 独 具 一 格 的 集中 式 管 理 模式 ， 在 本 书 第 5 篇 第 32 章 有 详 


细 介 绍 。 


即使 是 非 Android 项 目 ， 也 可 以 使 用 这 两 款 工具 为 自己 的 项 目 服 
务 。 我 还 为 repo 写 了 几 个 新 的 子 命令 以 实现 脱离 Gerrit 提 交 ， 计 repo 拥 
有 更 广泛 的 应 用 领域 。 


5. 定 制 开发 程序 员 


当 一 个 公司 的 软件 产品 需要 针对 不 同 的 用 户 进行 定制 开发 时 ， 束 
需要 在 一 个 版 本 库 中 建立 大 量 的 特性 分 文 ， 使 用 SVN 的 分 文 管理 远 不 
如 使 用 Git 的 分 支管 理 那 么 目 然 和 方便 。 还 有 一 个 应 用 领域 束 是 对 第 二 
方 代码 进行 维护 。 当 使 用 SVN 进 行 版 本 控制 时 ， 最 目 然 的 选择 是 卖主 


分 文 ， 但 随 着 定制 开发 的 逐渐 深入 ， 与 上 游 的 偏离 也 会 越 大 ， 于 是 与 
上 游 代 码 的 合并 也 将 越 来 越 令 人 痛 否 。 


第 4 篇 第 22 章 介绍 Topgit 文 一 杀手 级 的 工具 ， 这 是 这 个 领域 最 佳 的 
解决 方案 。 


6.SVN 用 户 


商业 软件 的 研发 团队 因为 需要 精细 的 代码 授权 ， 所 以 不 会 轻易 更 
换 现 有 的 SVN 版 本 控制 系统 ， 这 种 情况 下 Git 依 然 大 有 作为 。 无 论 是 出 
差 在 外 ， 或 是 在 家 办 公 ， 或 是 开发 团队 分 处 异地 ， 都 会 遇 到 SVN 版 本 
控制 服务 器 无 法 访问 或 速度 较 慢 的 情况 。 这 时 git-svn 这 一 工具 会 将 Git 
和 SVN 完 美 地 结合 在 一 起 ， 既 严格 遵守 SVN 的 授权 规定 ， 叉 可 以 自如 
地 进行 本 地 提交 ， 当 能 够 连接 到 SVN 服 务 器 时 ， 可 以 在 悠闲 地 喝 着 绿 
茶 的 同时 ， 等 待 一 次 性 批量 提交 的 完成 。 


我 有 几 个 项 目 (pySvnManager、Freemind-MMX) 托管 在 
SourceForge 的 SVN 服 务 器 上 ， 现 在 都 是 先 通 过 git-svn 将 其 转化 为 本 地 
的 Git 库 ， 然 后 再 使 用 的 。 以 这 样 的 方式 访问 历史 数据 、 比 较 代 码 或 提 
交代 码 ， 再 也 不 会 因为 网 速 太 慢 而 望 眼 欲 罕 了 。 


本 书 第 4 篇 第 26 章 详细 介绍 了 Git 和 SVN 的 互 操 作 。 


7. 管 理 


江 


~ 


Git 在 很 大 程度 上 减轻 了 管理 员 的 负担 : 分 文 的 创建 和 删除 不 再 需 
要 管理 员 统 一 管理 ， 因 为 作为 分 布 式 版 本 控制 系统 ， 每 一 个 克隆 束 古 
一 个 分 文 ， 每 一 个 克隆 都 拥有 独立 的 分 文 命名 空间 ;管理 员 也 不 再 需 
要 为 版 本 库 的 备份 操心 ， 因 为 每 一 个 项 目 成 员 都 拥有 一 个 备份 ， 管 理 
员 也 不 必 担 心 有 和 人 在 服务 器 上 得 改版 本 库 ， 因 为 Git 版 本 库 的 每 一 个 对 
象 《提交 和 文件 等 ) 都 使 用 SHA1 哈 希 值 进行 完整 性 校 验 ， 任 何 对 历史 
数据 的 修改 都 会 因为 对 后 续 提 区 产生 的 连锁 反应 而 原形 毕露 。 


本 书 第 7 篇 第 37 章 介绍 了 一 于 我 开发 的 基于 Git 的 备份 工具 ， 它 使 
得 Linux 系 统 的 数据 备份 易如反掌 。 本 书 第 5 篇 介绍 的 Git 服 务 右 搭建 ， 
以 及 第 6 篇 介绍 的 版 本 库 迁 移 方面 的 知识 会 为 版 本 控制 管理 员 的 日 常 维 
护 工 作 提 供 指 引 。 


8 开发 等 理 


作为 开发 经 理 ， 你 一 定 要 对 代码 分 文 有 次 刻 的 理解 ， 不 知 本 书 第 
18 草 中 的 “代码 管理 之 殊 ? 征 否 能 引起 你 的 共鸣。 为 了 能 在 各 种 情况 下 
恰当 地 管理 开发 团队 ， 第 4 篇 “Git 协 同 模型 ”是 项 目 经 理应 该 关注 的 重 
上 态 。 你 的 团队 是 否 存 在 着 跨 平 台 开 发 ， 或 者 潜在 着 跨 平台 开发 的 可 
能 ? 本 书 第 8 篇 第 40 章 也 是 开发 经 理应 当头 注 的 内 容 。 


排版 约定 


本 书 使 用 的 排版 格式 约定 如 下 : 
1. 命 令 输出 及 示例 代码 
执行 一 条 Git 命 令 及 其 输出 的 示例 如 下 : 


$git--version 
git version 1.7.4 


2. 提 示 符 (9$) 
命令 前 面 的 $ 符 号 代表 命令 提示 符 。 


3. 等 宽 字 体 (Constant width) 


用 于 标示 屏幕 输出 的 字符 、 示 例 代 码 ， 以 及 正文 中 出 现 的 命令 


参数 、 文 件 名 和 国 数 名 等 。 


4. 等 宽 粗 体 (Constant width bold) 


用 于 表示 由 用 户 手工 输入 的 内 容 。 


5. 占 位 符 (< Constant width > ) 


用 尖 括 号 扩 起 来 的 内 容 ， 表 示 命 令 中 或 代码 中 的 占 位 符 ， 读 者 应 
当 用 实际 值 将 其 替换 。 


在 线 质 源 


官方 网 站 : http://www.ossxp.com/doc/gotgit/ 


在 本 书 的 官方 网 站 上 ， 大 家 可 以 了 解 到 与 本 书 相 关 的 最 新 信息 ， 
查看 本 书 的 勘误 ， 以 及 下 载 与 本 书 相关 的 资源 。 官 网 是 以 Git 方 式 维护 
的 ， 人 人 都 可 以 参与 其 中 。 


新 良 微 博 : http://weibo.com/GotGit 


欢迎 大 家 通过 新 浪 微 博 与 作者 交流 ， 也 欢迎 大 家 通过 新 浪 微 博 将 
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第 1 篇 ” 初 识 Git 


Git 十 一 款 分 布 式 版 本 控制 系统 ， 有 别 于 CVS 和 SVN 等 集中 式 版 本 
控制 系统 ，Git 可 以 让 研发 团队 更 加 高 效 地 协同 工作 ， 从 而 提高 生产 
率 。 使 用 Git， 开 发 人 员 的 工作 不 会 因为 频繁 地 遭遇 提交 冲突 而 中 断 ， 
管理 人 员 也 无 须 为 数据 的 备份 而 担心 。 经 过 Linux 这 样 的 庞大 项 目的 考 
验 之 后 ，Git 锌 证 明 可 以 胜任 任何 规模 的 团队 ， 即 便 团队 成 员 分 布 于 世 
界 各 地 。 


Git 十 开源 社区 奉献 给 每 一 个 人 的 宝贝 ， 用 好 它 不 仅 可 以 实现 个 人 
的 知识 积 素 、 保 护 好 目 己 的 数据 ， 而 且 还 能 与 他 人 分 皇 目 己 的 成 采 。 
这 在 其 他 的 很 多 版 本 控制 系统 中 征 不 可 想象 的 。 你 会 为 个 人 的 版 本 控 
制 而 花费 高 易 的 费用 去 购买 商业 版 本 控制 工具 吗 ? 你 会 去 使 用 必须 搭 
建 额外 的 服务 器 才能 使 用 的 版 本 控制 系统 吗 ? 你 会 把 “鸡蛋 ” 放 在 具有 
单 扣 故障、 服务器 软 人 硬件 有 可 能 月 演 的 唯一 的 “竹子 ”里 吗 ? 如 果 你 不 


会 ， 那 么 选择 Git， 一 定 是 最 明智 的 选择 。 


本 篇 我 们 首先 用 一 章 的 内 容 来 回顾 一 下 版 本 控制 的 历史 ， 并 以 此 
向 版 本 控制 的 前 辈 CVS 和 SVN 致 敬 。 第 2 章 会 通过 一 些 典 型 的 版 本 控制 
实例 向 您 展示 Git 独 特 的 魅力 ， 让 您 爱 上 Git。 在 本 篇 的 最 后 一 章 会 介 
绍 Git 在 Linux、Mac OS X 及 Windows 下 的 安装 和 使 用 ， 这 是 我 们 进 一 
步 研 究 Git 的 基础 。 


在 这 里 有 必要 纠正 一 下 Git 的 发 音 。 一 种 错误 是 按照 单个 字母 来 发 
音 ， 另 外 一 种 更 为 普遍 的 错误 是 把 整个 单词 读 作 “ 技 特 ”， 实 际 上 Git 中 
字母 G 的 发 音 与 下 列 单词 中 的 G 类 似 : GOD、GIVES、GREAT、 
GIFT。 因 此 Git 正 确 的 发 音 应 该 听 起 来 像 是 “ 歌 易 特 ”。 本 书 的 英文 名 为 
《Got Git》 ， 当 面 对 这 样 的 书 名 时 您 还 会 把 Git 读 错 吗 ? 


第 1 章 ”版 本 控制 的 前 世 和 今生 


除了 茫然 未 知 的 宇 害 ， 几 乎 任何 事物 都 是 从 无 到 有 ， 从 人 简陋 到 完 
善 。 随 着 时 间 车 轮 的 滚滚 向 前 ， 历 史 被 抛 在 映 后 逐渐 远 去 ， 如 同 我 们 
的 现代 社会 ， 世 界 大 同 ， 到 处 都 是 忙 入 和 喧嚣 ， 再 也 看 不 到 已 经 远 去 
的 刀 耕 火种 、 男 耕 女 织 的 慢 生 活 妇 月 。 


版 本 控制 系统 是 一 个 另类。 里 然 其 历史 并 不 短暂 ， 也 有 几 十 年 ， 
但 是 它 的 演进 进程 却 一 直 在 社会 的 各 个 角落 重复 着 ， 而 且 尺 人 的 相 
似 。 有 的 人 从 未 使 用 甚至 从 未 听 说 过 版 本 控制 系统 ， 他 和 他 的 团队 丈 
像 集 留 在 黑暗 的 史前 时 代 ， 任 由 数据 目 生 目 炙 。 有 的 人 使 用 着 有 几 十 
年 历史 的 CVS 或 其 改良 版 Subversion， 让 时 间 空 耗 在 网 络 连接 的 等 待 
中 。 以 Git 为 代表 的 分 布 式 版 本 控制 系统 已 经 风靡 整个 开源 社区 ， 正 等 
待 你 的 靠近 。 


1.1 壮 暗 的 史前 时 代 


谈 及 远古 ， 人 们 总 爱 以 “黑暗 ”来 形容 。 黑 瞳 实 际 上 指 的 钙 秩 序 和 
工具 的 区 乏 ， 而 不 是 目 然 。 如 有 果 以 目 然 环境 而 论 ， 由 于 工业 化 和 城市 
化 对 环境 的 破坏 ， 现 今 才 是 最 黑暗 的 年 代 。 对 于 软件 开发 来 说 也 是 如 
此 ， 在 C 语 言 一 统 天 下 的 日 子 里 我 们 的 选择 很 简单 ， 如 今 面 临 
Java、.Net 和 脚本 语言 时 ， 我 们 的 选择 变 得 复杂 起 来 ， 但 是 从 工具 和 秩 
序 上 讲 ， 过 去 的 年 代 是 黑暗 的 。 


回顾 一 下 我 经 历 的 版 本 控制 的 “史前 时 代 * 吧 。 在 大 学 里 ， 代 码 分 
散 地 拷贝 在 各 个 软盘 中 ， 最 终 我 被 捅 糊涂 ， 不 知道 哪个 软盘 中 的 代码 
是 最 优 的 ， 因 为 最 新 并 非 最 优 ， 失 败 的 重 构 会 毁 掉 原来 尚 能 运作 的 代 
码 。 在 我 工作 的 第 一 年 ， 代 码 的 管理 并 未 得 到 改善 ， 还 是 以 简单 的 目 
录 找 贝 进行 数据 的 备份 ， 三 四 个 程序 员 利 用 文件 服务 器 的 共享 目录 进 
行 协同 ， 公 共 类 库 和 头 文件 在 操作 过 程 中 相互 覆盖 ， 痛 否 不 堪 。 很 明 
显 ， 那 时 我 尚 不 知道 版 本 控制 系统 为 何 物 。 我 的 版 本 控制 史前 时 代 一 
直 延 续 到 2000 年 ， 那 时 CVS 已 经 诞生 了 14 年 ， 而 我 在 那 时 对 CVS 还 一 
无 所 知 。 


实际 上 ， 即 便 是 在 CVS 出 现 之 前 的 “史前 时 代 ”， 也 已 经 有 了 非常 
好 用 的 用 于 源码 比较 和 打 补 丁 的 工具 : diff 和 patch， 它 们 今天 生命 力 
依然 顽强 。 大 名 风电 的 Linus Torvalds 先 生 (Linux 之 父 ) 也 对 这 两 个 工 
具 偏 爱 有 加 ， 在 1991~2002 年 之 间 ，Linus 一 直 顽 固 地 使 用 diff 、patch 
和 tar 包 管理 着 Linux 的 代码 ， 虽 然 不 断 有 人 提醒 他 有 CVS 的 存在 中 。 


那么 来 看 看 diff 和 patch， 沈 
存储 ) 和 使 用 版 本 控制 系统 
处 o 


它们 将 对 理解 版 本 控制 系统 (差异 
(代码 比较 和 冲突 解决 ;都 有 莫大 的 好 


1. 用 diff 命 令 比 较 两 个 文本 文件 或 目录 的 差异 


先 来 构造 两 个 文件 : 


文件 hello 
应 该 杜绝 文章 中 的 错 别 子 - 


但 是 无 论 使 用 
* 全 拼 ， 双 拼 
* 还 是 五 笔 


是 人 就 有 可 能 犯错 ， 软 件 更 是 如 此 -。 


犯 了 错 ， 就 要 扣 工 资 ! 


改正 的 成 本 可 能 会 很 高。 


对 这 两 个 文件 执行 diff 命 令 
diff.txt 文 件 中 。 


$diff-u hello world>diff.txt 


上 面 执行 diff 命 令 的 -u 参 


打开 文件 diff.txt， 会 看 到 其 


文件 world 
应 该 杜绝 文章 中 的 错别字 。 


但 是 无 论 使 用 

* 全 拼 ， 双 拼 

* 还 是 五 笔 

是 人 就 有 可 能 犯错 ， 软 件 更 是 如 此 。 


改正 的 成 本 可 能 会 很 高 ， 


但 是 “只 要 眼球 后 多 ， 所 有 Bug 都 好 氟 ”， 
这 就 是 开源 的 后 学: 


通过 输出 重 定 同 ， 将 差异 保存 在 


参数 很 重要 ， 使 得 差异 输出 中 带 有 上 下 文 。 
中 的 差异 比较 结果 。 为 了 说 明 方 便 ， 为 每 


---hello 2010-09-21 17:45:33.551610940+0800 
+++wWworld 2010-09-21 17:44:46.343610465+0800 
QQ@-1,4+1, 4@@ 

-应 该 杜绝 文章 中 的 错 别 子 。 

+ 应 该 杜绝 文章 中 的 错别字 。 


帮 
帮 


> 


但 是 无 论 使 用 
* 全 拼 , 双 拼 
9 QQ-6, 6+6, 700 


11 是 人 就 有 可 能 犯错 , 软件 更 是 如 此 。 


oo ~LIOOA 上 wm 站 


13 - 犯 了 错 , 就 要 扣 工 资 ! 


15 改正 的 成 本 可 能 会 很 高 。 
16 + 
17 + 但 是 “只 要 眼球 足够 多 , 所 有 Bug 都 好 捉 ”， 
18 + 这 束 是 开源 的 哲学 之 一 。 


S 


上 面 的 差异 文件 ， 可 以 这 么 理解 : 


第 1 行 和 第 2 行 分 别 记录 了 原始 文件 和 目标 文件 的 文件 名 及 时 间 
礁 。 以 三 个 减 号 (---) 开始 的 行 标识 的 是 原始 文件 ， 以 三 个 加 号 
(+++) 开始 的 行 标 识 的 是 目标 文件 。 


在 比较 内 容 中 ， 以 减 号 (-) 开始 的 行 是 只 出 现在 原始 文件 中 的 


行 ， 例如: 第 4、13、14 行 。 


在 比较 内 容 中 ， 以 加 号 (+) 开始 的 行 是 只 出 现在 目标 文件 中 的 
行 ， 例 如 : 第 5 行 和 16-18 行 。 


在 比较 内 容 中 ， 以 空格 开始 的 行 ， 是 在 原始 文件 和 目标 文件 中 都 
出 现 的 行 ， 例 如 : 第 6-8、10-12 和 第 15 行 。 这 些 行 是 用 作 差 异 比较 的 
3 


第 3-8 行 是 第 一 个 差异 小 节 。 每 个 差异 小 下 以 一 行 关 异 定位 语句 开 
始 。 第 3 行 束 古 一 条 差异 定位 语句 ， 其 前 后 分 别 用 两 个 @ 进 行 标识 。 


第 3 行 定位 语句 中 -1，4 的 含义 是 : 本 差异 小 节 的 内 容 相当 于 原始 
文件 的 从 第 1 行 开 始 的 4 行 。 而 第 4、6、7、8 行 是 原始 文件 中 的 内 容 ， 
加 起 来 刚好 是 4 行 。 


第 3 行 定位 语句 中 +1，4 的 含义 是 : 本 差异 小 节 的 内 容 相 当 于 目标 
文件 的 从 第 1 行 开 始 的 4 行 。 而 第 5、6、7、8 行 是 目标 文件 中 的 内 容 ， 
加 起 来 刚好 是 4 行 。 


因为 命令 diff 是 用 于 行 比较 的 ， 所 以 即使 改正 了 一 个 字 ， 也 显示 为 
一 整 行 的 修改 (参见 差异 文件 第 4、5 行 ) 。Git 对 diff 进 行 了 扩展 ， 并 
且 还 提供 一 种 逐 词 比较 的 差异 比较 方法 ， 参 见 本 书 第 2 篇 的 第 11.4.4 小 


+ 


| O 


第 9-18 行 是 第 二 个 差异 小 节 。 第 9 行 是 一 条 差异 定位 语句 。 


第 9 行 定位 语句 中 -6，6 的 含义 是 : 本 差异 小 节 的 内 容 相当 于 原始 
文件 的 从 第 6 行 开始 的 6 行 。 第 10-15 行 是 原始 文件 中 的 内 容 ， 加 起 来 刚 


好 是 6 行 。 


第 9 行 定 位 语句 中 +6，7 的 含义 是 : 本 差异 小 节 的 内 容 相当 于 目标 
文件 的 从 第 6 行 开始 的 7 行 。 而 第 10-12、15-18 行 是 目标 文件 中 的 内 
容 ， 加 起 来 刚好 是 7 行 。 


2. 命 令 patch 相 当 于 diff 的 反 回 操作 


有 了 hello 和 diff.txt 文 件 ， 可 以 放心 地 将 world 文 件 删 除 或 用 hello 文 
件 将 world 文 件 覆 盖 。 用 下 面 的 命令 可 以 还 原 world 文 件 : 


$cp hello world 
$patch world<diff.txt 


也 可 以 保留 world 和 diff.txt 文 件 ， 删 除 hello 文 件 或 用 word 文 件 将 
hello 文 件 履 盖 。 用 下 面 的 命令 可 以 恢复 hello 文 件 : 


$cp world hello 
$patch-R hello<diff.txt 


命令 dif 和 patch 还 可 以 对 目录 进行 比较 操作 ， 这 也 就 是 Linus 在 
1991~2002 年 用 于 维护 Linux 不 同 版 本 间 差 异 的 办 法 。 在 没有 版 本 控制 
系统 的 情况 下 ， 可 以 用 此 命令 记录 并 保存 改动 前 后 的 差异 ， 还 可 以 将 
差异 文件 注入 版 本 控制 系统 (如 果 有 的 话 ) 。 


标准 的 diff 和 patch 命 令 存 在 一 个 局 限 ， 吏 是 不 能 对 二 进 制 文件 进 
行 处 理 。 对 二 进 制 文件 的 修改 或 添加 会 在 差异 文件 中 缺失 ， 进 而 丢失 
对 二 进 制 文件 的 改动 或 添加 。Git 对 差异 文件 格式 提供 了 扩展 文 持 ， 文 
持 二 进 制 文件 的 比较 ， 解 决 了 这 个 问题 。 这 一 点 可 以 参考 本 书 第 7 篇 第 
38 章 的 相关 内 容 。 


[1] Linus Torvalds 于 2007 年 5 月 3 日 在 Google 的 演讲 : 
http://www.youtube.com/watch? v=4XpnKHJAok8 
[2] 此 处 是 故意 将 “ 字 ” 写 成 < 子 ”"， 以 便 两 个 文件 进行 差异 比较 。 


1.2 CVS 一 一 开局 厂 本 控制 大 霖 发 


CVS (Concurrent Versions System) 站 诞生 于 1985 年 ， 是 由 和 荷兰 
阿姆斯特丹 VU 大 学 的 Dick Grune 教 授 实 现 的 。 当 时 Dick Grune 和 两 个 
学 生 共同 开发 一 个 项 目 ， 但 是 三 个 人 的 工作 时 间 无 法 协调 到 一 起 ， 迫 
切 需 要 一 个 记录 和 协同 开发 的 工具 软件 。 于 是 Dick Grune 通 过 脚本 语 
言 对 RCS (一 个 针对 单独 文件 的 版 本 管理 工具 ) 进行 封装 ， 设 计 出 有 
史 以 来 第 一 个 被 大 规模 使 用 的 版 本 控制 工具 。Dick 教 授 的 网 站 上 介绍 
了 CVS 的 这 段 早 期 历史 。 站 


“在 1985 年 的 一 个 粳 糙 的 秋 日 里 ， 我 在 校 汽车 站 等 和 车 回 家 ， 脑 海里 
一 直 纠 结 着 一 件 事 一 一 如 何 处 理 RCS 文 件 、 用 户 文 件 (工作 区 ) 和 
Entries 文 件 的 复 洒 关系 ， 有 的 文件 可 能 会 缺失 、 冲 突 、 删 除 ， 等 等 。 
我 的 头 有 些 棠 了， 于 征 决 定 画 一 个 大 表 ， 将 复杂 的 关联 画 在 其 中 ， 看 
看 出 来 的 结 采 是 什么 样 的 .…...” 


1986 年 Dick 通 过 新 闻 组 发 布 了 CVS，1989 年 Brian Berliner 用 Ci 语言 
将 CVS 进 行 了 重 写 。 


从 CVS 的 历史 可 以 看 出 ，CVS 不 是 设计 出 来 的 ， 而 是 被 实际 需 
要 “ 通 ? 出 来 的 ， 因 此 根据 “实用 为 上 ”的 原则 ， 借 用 了 已 有 的 针对 单一 
文件 的 版 本 管理 工具 RCS。CVS 采 用 客户 端 /服务 右 架 构 设 计 ， 版 本 库 


位 于 服务 器 端 ， 实 际 上 就 是 一 个 RCS 文 件 容器 。 每 一 个 RCS 文 件 以 "， 
v" 作 为 文件 名 后 缀 ， 用 于 保存 对 应 文件 的 每 一 次 更 改 历史 。RCS 文 件 
中 只 保留 一 个 版 本 的 完全 拷贝 ， 其 他 历次 更 改 仅 将 差异 存储 其 中 ， 使 
得 存储 变 得 非常 有 效率 。 我 在 2008 年 设计 了 一 个 SVN 管 理 后 台 
pySvnManager Dll ， 实 际 上 也 采用 了 RCS 作 为 SVN 授 权 文 件 的 变更 记录 
的 “数据 库 ”。 


图 1-1 展 示 了 CVS 版 本 控制 系统 的 工作 原理 ， 可 以 看 到 作为 RCS 文 
件 容器 的 CVS 版 本 库 和 工作 区 目录 结构 的 一 一 对 应 关系 。 


| 筷 ” Cvs 版 本 库 es 村 | 让 


站 一 项 目 一 | V3=V2+a2 | 工 本 Taa1 
是 V4=V3+*43 -Ta01 Wg 作 区 (版 ag ) 
NVS5=V4+A4 -Tag2/ 
[一 三 |hello.c,v j。 ， 
一 ~ 9 V2nV152AT1 :Tag1 1 
V3nV2vA2: Tag2 三 jhello.c 
~ hello.h,y < | 
二 “三 jhelloh 
doc V1 ; Tag2 本 RN 
三 |Readme,v V1 
一 台 |Makefile 天 一 
三 | Makefile,v ~ 
Eee 3 注 : 工作 区 中 略 去 目录 CYS 


- 力 项 目 二 


图 1-1 CVS 版 本 控制 系统 示意 图 


CVS 这 种 实现 方式 的 最 大 好 处 束 是 简单 。 把 版 本 库 中 任意 一 个 目 
录 拿 出 来 束 可 以 成 为 男 外 一 个 版 本 库 。 如 果 将 版 本 库 中 的 一 个 RCS 文 
件 重 命名 ， 工 作 区 检 出 的 文件 名 也 会 相应 地 改变 。 这 种 低 成 本 的 服务 
右 管 理 模 式 成 为 很 多 CVS 粉 丝 至 今 不 愿 离 开 CVS 的 原因 。 


CVS 的 出 现 让 软件 工程 师 认 识 到 了 原来 还 可 以 这 样 工作 。CVS 成 
功 地 为 后 来 的 版 本 控制 系统 确立 了 标准 ， 像 提交 说 明 (commit 
log) “、 检 入 (checkin) 、 检 出 (checkout) 、 里 程 碑 (tag) 、 分 支 
(branch) 等 概念 在 CVS 中 早 就 已 经 确立 。CVS 的 命令 行 格式 也 被 后 
来 的 版 本 控制 系统 竞相 模仿 。 


在 2001 年 ， 我 正 为 使 用 CVS 激 动 不 已 的 时 候 ， 公 司 领 导 要 求 采用 
和 美国 研发 部 门 同样 的 版 本 控制 解决 方案 。 于 是 ， 我 的 项 目 组 率先 进 
行 了 从 CVS 到 该 商业 版 本 控制 工具 的 迁移 绰 。 虽 然 商业 版 本 控制 工具 
有 更 漂亮 的 界面 及 更 好 的 产品 整合 性 ， 但 是 就 版 本 控制 本 吴 而 言 ， 商 
业 版 本 控制 工具 存在 着 如 下 缺陷 。 


采用 黑 盒 子 式 的 版 本 库 设 计 。 让 人 捉摸 不 透 的 版 本 库 设计 ， 最 主 
要 的 目的 可 能 束 是 阻止 用 户 再 迁移 到 其 他 平台 。 


缺乏 版 本 库 整 理工 具 。 如 采 有 一 个 文件 〈 如 记录 核 阐 引爆 密码 的 
文件 ) 检 入 到 版 本 库 中 ， 就 无 法 再 彻底 移 除 它 。 


商业 版 本 控制 工具 很 难为 个 人 提供 版 本 控制 解决 方案 ， 除 非 个 人 
愿意 花费 高 昂 的 许可 证 费用 。 


商业 版 本 控制 工具 注定 是 小 众 软 件 ， 新 员工 的 培训 成 本 不 可 忽 
ts 


而 上 述 商 业 版 本 控制 系统 的 缺点 恰恰 是 CVS 及 其 他 开源 版 本 控制 
系统 的 优点 。 但 在 经 历 了 最 初 的 成 功 之 后 ，CVS 也 尽 显 疲 态 : 


服务 器 端 松散 的 RCS 文 件 导致 在 建立 里 程 碑 或 分 支 时 效率 不 高 ， 
服务 器 端 文件 越 多 ， 速 度 越 慢 


分 支 和 里 程 碑 不 可 见 ， 因 为 它们 被 分 散 地 记录 在 服务 器 端的 各 个 
RCS 文 件 中 。 

合并 困难 重重 ， 因 为 缺乏 对 合并 的 追踪 ， 从 而 导致 重复 合并 ， 引 
发 严重 冲突 。 


缺乏 对 原 于 提交 的 文 持 ， 会 导致 客户 端 癌 服务 天 端 提交 不 完整 的 
数据 。 


不 能 优化 存储 内 容 相 同 但 文件 名 不 同 的 文件 ， 因 为 在 服务 器 端 每 
个 文件 都 臣 单 独 进行 差异 存储 的 。 


不 能 对 文件 和 目录 的 重 命名 进行 版 本 控制 ， 虽 然 直 接 在 服务 句 端 
修改 RCS 文 件 名 可 以 让 改名 后 的 文件 体 存 历史 ， 但 是 这 样 做 实际 上 会 
破坏 历史 。 


CVS 的 成 功 导致 了 版 本 控制 系统 的 大 爆发 ， 各 式 各 样 的 版 本 控制 
系统 如 雨 后 春 穷 般 诞 生 了 “。 新 的 版 本 控制 系统 或 多 或 少 地 解决 了 CVS 


版 本 控制 系统 存在 的 问题 。 在 这 些 版 本 控制 系统 中 ， 节 典型 的 束 是 


Subversion (SVN) 。 


[1| http:/www.nongnu.org/cvs/ 

[2| http://dickgrune.com/Programs/CVS.orig/ 

[3] http://pysvnmanager.sourceforge.net 

[4] 于 是 束 有 了 这 篇 文 


http://www.worldhello.net/doc/cvs_vs_starteam 


攻 


1.3 ”SVN 一 一 集中 式 版 本 控制 集大成 者 


Subversion 1 ， 由 于 其 命令 行 工 具名 为 swn， 因 此 通常 被 简称 为 
SVN。SVN 由 CollabNet 公 司 于 2000 年 资助 并 开始 开发 ， 目 的 是 创建 一 
个 更 好 用 的 版 本 控制 系统 以 取代 CVS。SVN 的 前 期 开发 使 用 CVS 做 版 
本 控制 ， 到 了 2001 年 ，SVN 已 经 可 以 用 于 自己 的 版 本 控制 了 中。 


我 开始 真正 关注 SVN 是 在 2005 年 ， 那 时 SVN 正 经 历 着 后 端 存储 上 
的 变革 ， 即 从 BDB (简单 的 关系 型 数据 库 ) 到 FSFS (文件 数据 库 ) 的 
转变 。 相 对 于 BDB 而 言 ，FSFS 具 有 稳定 、 免 维护 和 实现 的 可 视 性 高 等 
优点 ， 于 是 我 马上 束 彼 SYN 吸引 了 。 图 1-2 展 示 了 SVN 版 本 控制 系统 的 
工作 原理 。 


[篇 ”SVN 版 本 库 Ss 客户 端 
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注 : 工作 区 中 略 去 目录 . syn 


图 1-2 SVN 版 本 控制 系统 示意 图 


SVN 的 每 一 次 提交 ， 都 会 在 服务 器 端的 db/revs 和 db/revprops 目 永 
下 各 创建 一 个 以 顺序 数字 编号 命名 的 文件 。 其 中 ，db/revs 目 录 下 的 文 
件 ( 即 变更 集 文件 ) 记录 了 与 上 一 个 提交 之 间 的 差异 (字母 A 表示 新 
增 ，M 表 示 修 改 ，D 表 示 删 除 ) 。 在 db/revprops 目 录 下 的 同名 文件 〈 没 
有 在 图 1-2 中 体现 ) 则 保存 着 提交 日 志 、 作 者 、 提 交 时 间 等 信息 。 这 样 
设计 的 好 处 有 : 


拥有 全 局 版 本 号 。 每 提交 一 次 ，SVN 的 版 本 号 就 会 自动 加 一 。 这 
为 SVN 的 使 用 提供 了 极 大 的 便利 。 回 想 CVS 时 代 ， 每 个 文件 都 拥有 各 
目 独立 的 版 本 号 (RCS 版 本 号 ) ， 要 想 获 得 全 局 版 本 号 ， 只 能 通过 手 
工 不 断 地 建立 里 程 碑 来 实现 。 


实现 了 原子 提交 。SVN 不 会 像 CVS 那 样 出 现 文件 的 部 分 内 容 被 提 
交 而 其 余 的 内 容 没 有 被 提交 的 情况 。 


文件 名 不 受 限 制 。 因 为 服务 句 端 不 再 需要 建立 和 客户 端 文件 相似 
的 文件 名 ， 于 是 ， 文 件 的 命名 束 不 再 受 服 务 絮 控 作 系统 的 字符 集 和 大 
小 写 的 限制 。 


文件 和 目录 重 命名 也 得 到 了 文 持 。 


SVN 最 具有 特色 的 功能 是 轻 量 级 找 贝 ， 例 如 将 目录 trunk 找 贝 为 
branches/v1.x 只 相当 于 在 db/revs 日 录 中 的 变更 集 文件 中 用 特定 的 语法 做 
了 一 下 标注 ， 无 须 真正 的 文件 找 贝 。SVN 使 用 轻 量 级 拷贝 的 功能 ， 轻 


松 地 解决 了 CVS 存 在 的 里 程 碑 和 分 支 的 创建 速度 慢 又 不 可 见 的 问题 ， 
使 用 SVN 创 建 里 程 碑 和 分 支 只 在 及 上 服 之 间 。 


SVN 在 版 本 库 授权 上 也 有 改进 ， 不 再 像 CVS 那 样 依赖 探 作 系 统 
身 对 版 本 库 目 录 和 文件 进行 授权 ， 而 是 采用 授权 文件 的 方式 来 实现 。 


SVN 还 有 一 个 创举 ， 就 是 在 工作 区 跟踪 目录 下 (.svn 目 录 ) 为 当 
前 目 邓 中 的 每 一 个 文件 者 保存 一 份 见 余 的 原始 拷贝 。 这 样 做 的 好 处 十 
部 分 命令 不 再 需要 网 络 连接 ， 例 如 文件 修改 的 差异 比较 ， 以 及 错误 更 
改 的 回 退 等 。 


正 征 由 于 这 些 内 亮 的 功能 特性 ， 才 使 得 SVN 在 CVS 之 后 诞生 的 请 
多 版 本 控制 系统 中 脱 壬 而 出 ， 成 为 开源 社区 一 时 的 新 容 ， 也 成 为 当时 
各 个 企业 进行 版 本 控制 的 最 佳 选择 之 一 。 


但 是 ， 相 对 于 CVS,SVN 在 本 质 上 并 没有 突破 ， 都 属于 集中 式 版 本 
控制 系统 。 即 一 个 项 目 只 有 唯一 的 一 个 版 本 库 与 之 对 应 ， 所 有 的 项 目 
成 员 都 通过 网 络 向 该 服务 器 进行 提交 。 这 样 的 设计 除了 容易 出 现 单 点 
故障 以 外 ， 在 查看 日 志和 提交 数据 等 操作 时 的 延迟 ， 会 让 基于 广域网 
协同 工作 的 团队 抓 狂 。 


除了 集中 式 版 本 控制 系统 回 有 的 问题 外 ，SVN 的 里 程 碑 和 分 文 的 
设计 也 被 证 明 是 一 个 错误 ， 虽然 这 个 错误 的 设计 使 得 SVN 拥 有 了 快速 


创建 里 程 碑 和 分 文 的 能 力 ， 但 是 这 个 错误 的 设计 也 导致 了 如 下 的 更 多 


问题 。 


项 目 文件 在 版 本 库 中 必须 按照 一 定 的 目 孙 结构 进行 部 署 ， 否 则 束 
可 能 无 法 建立 里 程 碑 和 分 文 。 


我 在 项 目 咨 询 过 程 中 见 过 很 多 团队 ， 直 接 在 版 本 库 的 根 目录 下 创 
建 项 目 文件 。 这 样 的 版 本 库 布 局 ， 在 需要 创建 里 程 碑 和 分 支 时 就 无 从 
下 手 了 ， 因 为 根 目录 是 不 能 揽 贝 到 子 目 录 中 的 。 所 以 SVN 的 用 户 在 创 
建 版 本 库 时 必须 遵守 一 个 古怪 的 约定 : 先 创建 三 个 顶级 目 
录 /trunk、/tags 和 /branches。 


创建 里 程 牧 和 分 文 会 破坏 精心 设计 的 授权 。 


SVN 的 授权 是 基于 目录 的 ， 分 支 和 里 程 碑 也 被 视 为 目录 (和 其 他 
目录 没有 分 别 ) 。 因 此 每 次 创建 分 文 或 里 程 碑 时 ， 就 要 将 针对 /trunk 目 
录 及 其 于 目录 的 授权 在 新 建 的 分 文 或 里 程 碑 上 重建 。 随 着 分 文 和 里 程 
碑 数 量 的 增多 ， 授 权 愈 加 复杂 ， 维 护 也 愈加 困难 。 


分 支 太 随意 从 而 导致 混乱 。SVN 的 分 文 创建 非常 随意 : 可 以 基 
于 /trunk 目 永 创 建 分 文 ， 也 可 以 基于 其 他 任何 目 永 创建 分 文 ， 因 此 SVN 
很 难 画 出 一 个 有 意义 的 分 文 图 。 再 加 上 一 次 提交 可 以 同时 包含 针对 不 
同 分 文 的 文件 变更 ， 使 得 事情 变 得 更 糟 。 


虽然 SVN 在 1.5 版 之 后 拥有 了 合并 追踪 功能 ， 但 这 个 功能 会 因为 混 
乱 的 分 支管 理 而 被 抵消 。 


2009 年 年 底 ，SVN 由 CollabNet 公 司 交 由 Apache 社 区 管理 ， 至 此 
SVN 成 为 了 Apache 组 织 的 一 个 子 项 目 沾 。 这 对 SVN 到 底 意 味 着 什么 ? 
是 开发 的 停滞 ? 还 是 新 的 开始 ? 结果 如 何 我 们 将 拭目以待 。 


[1| http://subversion.apache.org/ 
[2] http://svnbook.red- 
bean.com/en/1.5/svn.intro.whatis.html#svn.intro.history 


[3] http://en.wikipedia.org/wiki/Apache_Subversion 


1.4 Git Linus 的 第 二 个 伟大 作品 

Linux 之 父 Linus 是 坚定 的 CVS 反 对 者 ， 他 也 同样 地 反对 SVN。 这 
就 是 为 什么 在 1991-2002 这 十 余年 间 ，Linus 宁 可 以 手工 修补 文件 的 方 
式 维护 代码 ， 也 述 迟 不 愿 使 用 CVS 的 原因 。 我 想 在 当时 要 想 劝 说 Linus 
使 用 CVS 只 有 一 个 办 法 : 把 CVS 服 务 器 请 进 Linus 的 臣 宇 ， 并 对 外 配 以 


于 兆 市 宽 。 


2002 年 至 2005 年 ，Linus 顶 着 开源 社区 精英 们 口 诛 笔 伐 的 压力 ， 选 
择 了 一 个 商业 版 本 控制 系统 BitKeeper 作 为 Linux 内 核 的 代码 管理 工具 
上 山 。BitKeeper 不 同 于 CVS 和 SVN 等 集中 式 版 本 控制 工具 ， 而 是 一 款 分 
布 式 版 本 控制 工具 。 


分 布 式 版 本 控制 系统 最 大 的 反 传统 之 处 在 于 ， 可 以 不 需要 集中 式 
的 版 本 库 ， 每 个 人 都 工作 在 通过 克隆 建立 的 本 地 版 本 库 中 。 也 就 是 说 
每 个 人 都 拥有 一 个 完整 的 版 本 库 ， 查 看 提交 日 志 、 提 交 、 创 建 里 程 碑 
和 分 文 、 合 并 分 文 、 回 退 等 所 有 操作 都 直接 在 本 地 完成 而 不 需要 网 络 
连接 。 每 个 人 都 是 本 地 版 本 库 的 主人 ， 不 再 有 谁 能 提交 谁 不 能 提交 的 
限制 ， 加 上 多 样 的 协同 工作 模型 (版 本 库 间 推送 、 拉 回 ， 以 及 补丁 文 
件 传送 等 ) 让 开源 项 目的 参与 度 有 爆发 式 增长 。 


2005 年 发 生 的 一 件 事 最 终 导 致 了 Git 的 诞生 。 在 2005 年 4 月 ， 
Andrew Tridgell 〈《 即 大 名 导电 的 Samba 的 作者 ) 试图 对 BitKeeper 进 行 反 
向 工程 ， 以 开发 一 个 能 与 BitKeeper 交 互 的 开源 工具 。 这 激怒 了 
BitKeeper 软 件 的 所 有 者 BitMover 公 司 ， 要 求 收回 对 Linux 社 区 免费 使 用 
BitKeeper 的 授权 [了 。 迫 不 得 已，Linus 选 择 了 自己 开发 一 个 分 布 式 版 
本 控制 工具 以 蔡 代 BitKeeper。 以 下 是 Git 诞 生 过 程 中 的 大 事 记 站 : 


2005 年 4 月 3 日 ， 开 始 开发 Git。 


2005 年 4 月 6 日 ， 项 目 发 布 。 


2005 年 4 月 7 日 ，Git 束 可 以 作为 和 目 喘 的 版 本 控制 工具 了 。 


2005 年 4 月 18 日 ， 发 生 第 一 个 多 分 支 合 并 。 


2005 年 4 月 29 日 ，Git 的 性 能 就 已 经 达到 了 Linus 的 预期 。 


2005 年 6 月 16 日 ，Linux 内 核 2.6.12 发 布 ， 那 时 Git 已 经 在 维护 Linux 
核心 的 源 代码 了 。 


Linus 以 一 个 文件 系统 专家 和 内 核 设计 者 的 视角 对 Git 进 行 了 设 
计 ， 其 独特 的 设计 让 Git 拥 有 非 几 的 性 能 和 最 为 优化 的 存储 能 力 。 完 成 
原型 设计 后 ， 在 2005 年 7 月 26 日 ，Linus 功 成 身 退 ， 将 Git 的 维护 交 给 另 
外 一 个 Git 的 主要 贡献 者 Junio C Hamano [4 ， 直 到 现在 。 


最 初 的 Git 除 了 一 些 核心 命令 以 外 ， 其 他 的 都 用 脚本 语言 开发 ， 而 
且 每 个 功能 都 作为 一 条 独立 的 命令 ， 例 如 克隆 操作 用 gitrclone， 提 区 
操作 用 gitrcommit。 这 导致 Git 拥 有 庞大 的 命令 集 ， 使 用 习惯 也 和 其 他 
版 本 控制 系统 格格 不 入 。 随 着 Git 的 开发 者 和 使 用 者 的 增加 ，Git 也 在 
逐渐 演变 ， 例 如 到 1.5.4 版 本 时 ， 将 一 百 多 个 独立 的 命令 封 狠 为 一 个 git 
命令 ,使 它 看 起 来 更 像 是 一 个 独立 的 工具 ， 也 使 Git 更 贴近 于 普通 用 户 
的 使 用 习惯 。 


经 过 短 短 几 年 的 发 展 ， 从 多 的 开源 项 目 都 纷纷 从 SVN 或 其 他 版 本 
控制 系统 迁移 到 Git。 虽 然 版 本 控制 系统 的 迁移 过 程 是 痛 音 的 ， 但 是 因 
为 迁移 到 Git 会 带 来 开发 效率 的 极 大 提升 ， 以 及 巨大 的 效益 ， 所 以 很 快 
就 会 起 记 迁 移 的 痛 百 过 程 ， 而 且 很 快 束 会 适应 新 的 工作 模式 。 在 Git 的 
官方 网 站 上 列 出 了 几 个 使 用 Git 的 重量 级 项 目 ， 每 一 个 都 是 人 们 耳 熟 能 
详 的 ， 除 了 Git 和 Linux 内 核 外 ， 还 有 Perl、Edlipse、Gnome 、KDE 、 
Qt、Ruby on Rails、Android、PostgreSQL、Debian、X.org， 当 然 还 有 
GitHub 的 上 百 万 个 项 目 。 


Git 虽 然 是 在 Linux 下 开发 的 ， 但 现在 已 经 可 以 跨 平 台 运 行 在 所 有 
主流 的 操作 系统 上 ， 包 括 Linux、Mac OS X 和 Windows 等 。 可 以 说 每 一 
个 使 用 计算 机 的 用 户 都 可 以 分 享 Git 讲 来 的 便利 和 快乐 。 


[1| http://en.wikipedia.org/wiki/BitKeeper 
[2] http://en.wikipedia.org/wiki/Andrew_Tridgell 


[3] http://en.wikipedia.org/wiki/Git_%28software%29 
[4] http://marc.info/? l=git&m=112243466603239 


第 2 章 ” 爱 上 Git 的 理由 


本 章 将 通过 一 些 典 型 应 用 展示 Git 作 为 版 本 控制 系统 的 独特 用 法 ， 
不 熟悉 版 本 控制 系统 的 读者 可 以 通过 这 些 示例 对 版 本 控制 拥有 感性 的 
认识 。 如 果 是 有 经 验 的 读者 ， 示 例 中 Git 和 SVN 的 对 照 可 以 让 您 体会 到 
Git 的 神奇 和 强大 。 本 章 将 列举 Git 的 一 些 内 亮 特性 ， 期 等 能 够 让 您 爱 
上 Git。 


2 日 工作 备份 


当 我 开始 所 写本 书 时 才 明 日 写 书 真 的 是 一 个 圣 藻 活 。 如 何 让 鞋 否 
的 工作 不 会 因为 笔记 本 硬盘 的 意外 损坏 而 丢失 ? 如 何 防范 灾害 而 不 让 
一 个 篮子 里 的 鸡蛋 都 又 于 一 旦 ? 下 面 束 介绍 一 下 我 在 写本 书 时 是 如 何 
使 用 Git 进 行文 稿 备份 的 ， 请 看 图 2-1 。 


206.221.217 * 
192.1650.2 
© RC 


Ep 
192,168.0.100 


2-1 利用 Git 做 数据 的 备份 


如 图 2-1 所 示 ， 我 的 笔记 本 在 公司 局 域 网 里 的 IP 地 址 是 
192.168.0.100， 公 司 的 Git 服 务 器 的 耳 地 址 是 192.168.0.2。 公 司 使 用 动 
态 IP 上 网 因而 没有 固定 的 外 网 卫 ， 但 是 公司 在 数据 中 心 有 托 管 服务 
如 ， 拥 有 固定 的 IP 地 址 ， 其 中 一 台 服 务 器 用 作 Git 服 务 句 镜像 。 


我 的 写 书 习惯 大 概 是 这 样 : 在 写 完 一 个 小 节 或 是 画 完 一 张 图 后 ， 
我 会 执行 下 面 的 命令 提交 一 次 。 每 一 天 平均 提交 3-5 次 。 提 交 是 在 本 地 
完成 的 ， 因 此 在 图 中 没有 表示 出 来 。 


$git add-u# 如 果 创建 了 新 文件 , 可 以 执行 git add-i 命 令 。 
$git commit 


下 班 后 ， 我 会 执行 一 次 推送 操作 ， 将 我 在 本 地 Git 版 本 库 中 的 提交 
同步 到 公司 的 Git 服 务 器 上 “。 相 当 于 图 2-1 中 的 步 又。 


$git push 


因为 公司 的 Git 服 务 器 和 异地 数据 中 心 的 Git 服 务 器 建立 了 镜像 ， 
所 以 每 当 我 向 公司 内 网 服务 器 推送 的 时 候 ， 就 会 自动 触发 从 内 网 服务 
器 到 外 网 Git 服 务 器 的 镜像 操作 。 这 相当 于 图 2-1 中 的 步骤 2， 步骤 OO) 是 
自动 执行 的 ， 无 须 人 工 干 预 。 图 2-1 中 标记 为 mirror 的 版 本 库 就 是 Git 镜 
像 版 本 库 ， 该 版 本 库 只 向 用 户 提供 只 读 访 问 服务 ， 而 不 能 对 其 进行 写 
操作 (推送 ) 。 


从 图 2-1 中 可 以 看 出 ， 我 的 每 日 工作 保存 有 三 个 拷贝 ， 一 个 在 笔记 
本 中 ， 一 个 在 公司 内 网 的 服务 右上 ， 还 有 一 个 在 外 网 的 镜像 版 本 库 
中 。 鸡 蛋 分 别 效 在 了 三 个 篮子 里 。 


关于 如 何 架 设 可 以 实时 镜像 的 Git 服 务 器 ， 会 在 本 书 第 5 篇 第 30 章 


中 详细 介绍 。 


22 械 地 协同 工作 


为 了 能 够 加 快 写 书 的 进度 ， 菊 夜 是 必须 的 ， 这 吏 出 现 了 在 公司 和 
家 里 两 地 工作 同步 的 问题 。 图 2-2 用 于 说 明 我 是 如 何 解 决 两 地 工作 同步 
问题 的 。 


公司 局 域 网 数据 中 心 S| 
, 证 206.221.217* 
4 2 
、 j | 
家 
el a - 
192.168.0.126 192.168.0.100 10.0.0.100 


图 2-2 利用 Git 实 现 异 地 工作 协同 


我 在 家 里 的 电脑 PP 地址 是 10.0.0.100 (家 里 也 有 一 个 小 局 域 网 ) 。 
如 果 在 家 里 有 时 间 工 作 的 话 ， 首 先 要 做 的 就 是 图 2-2 中 步骤 人 的 操作 
将 mirror 版 本 库 中 的 数据 同步 到 本 地 。 只 需要 一 条 命令 就 好 了 : 


$git pull mirror master 


然后 在 家 里 的 电脑 上 继续 编写 书稿 并 提交 。 当 准备 完成 一 天 的 工 
作 后 ， 就 执行 下 面 的 命令 ， 相 当 于 图 2-2 中 步骤 由 的 操作 : 将 在 家 中 的 
提交 推送 到 标记 为 home 的 版 本 库 中 。 


$git push home 


为 什么 还 要 再 引入 另外 一 个 名 为 home 的 版 本 库 呢 ?使 用 mirror 版 
本 库 不 好 么 ? 不 要 起 了 mirror 版 本 库 只 是 一 个 镜像 库 ， 不 能 提供 写 操 
作 。 


当 一 早 到 公司 ， 开 始 动笔 写 书 之 前 ， 移 要 执行 图 2-2 中 步骤 的 操 
作 ， 从 home 版 本 库 将 家 里 做 的 提交 同步 到 公司 的 电脑 中 。 


$git pull home master 


公司 的 小 败 是 我 这 本 书 的 定 实 读者 ， 每 当 有 新 章节 完成 ， 他 都 会 
执行 图 2-2 中 步骤 的 工作 ， 从 公司 内 网 服务 器 获取 我 最 新 的 文稿 。 


$git pull 


一 旦 发 现 文 字 错 误 ， 小 上 窗 会 直接 在 文稿 中 修改 ， 然 后 推送 到 公司 
的 服务 器 上 《图 2-2 中 步骤 @O) 。 当 然 他 的 这 个 推送 也 会 自动 同步 到 外 
网 的 mirror 版 本 库 。 


$git push 


而 我 只 要 执行 git pull 操 作 就 可 以 获得 小 窄 对 文稿 的 修订 (图 2-2 中 
的 步 又 C8) 。 采 用 这 种 工作 方式 ， 文 稿 竟然 分 布 在 5 台电 脑 上 拥有 6 个 
拷贝 ， 真 可 训 狐 兔 二 窒 。 不 ， 比 狐 兔 还 要 多 二 宿 。 


在 本 节 中 ， 出 现在 Git 命 令 中 的 mirror 和 home 是 和 工作 区 关联 的 远 
程 版 本 库 。 关 于 如 何 注册 和 使 用 远程 版 本 库 ， 请 参见 本 书 第 3 篇 第 19 章 
中 的 内 容 。 


2.3 ”现场 版 本 控制 


所 谓 现场 版 本 控制 ， 束 是 在 客户 现场 或 在 产品 部 车 的 现场 进行 源 
代码 的 修改 ， 并 在 修改 过 程 中 进行 版 本 控制 ， 以 便 在 完成 修改 后 能 够 
将 修改 结 采 甚至 修改 过 程 一 并 市 走 ， 并 能 够 将 修改 结 采 合并 至 项 目 对 
应 的 代码 库 中 。 


1.SVN 的 解决 方案 


如 采 使 用 SVN 进 行 版 本 控制 ， 前 先 要 将 服务 絮 上 部 闭 的 闫 品 代码 
目 孙 变 成 SVN 工 作 区 ， 这 个 过 程 不 仅 不 倘 单 ， 而 且 会 显得 很 党 琐 ， 节 
后 将 改动 结果 导出 也 非常 不 方便 ， 具 体操 作 过 程 如 下 。 


(1) 在 其 他 位 置 建立 一 个 SVN 版 本 库 。 


$svnadmin create/path/to/repos/project1 


(2) 在 需要 版 本 控制 的 目录 下 检 出 刚刚 建立 的 空 版 本 库 。 


$svn checkout file:///path/to/repos/project1. 


(3) 执行 添加 文件 操作 ， 然 后 执行 提交 操作 。 这 个 提交 将 是 版 本 
库 中 编号 为 1 的 提交 。 


$svn add* 
$svn ci-m "initialized" 


(4) 开始 在 工作 区 中 修改 文件 并 提交 。 


$svn ci 


(5) 如 果 对 修改 结果 满意 ， 可 以 通过 创建 补丁 文件 的 方式 将 工作 
成 果 祭 存 并 之 走 。 但 是 SVN 很 难 针对 每 次 提交 逐一 创建 外 丁 ， 一 般 用 
下 面 的 命令 与 最 早 的 提交 进行 比较 ， 以 创建 出 一 个 大 补丁 文件 。 


$svn diff-r1l>hacks.patch 


上 面 用 SVN 将 工作 成 末 导 出 的 过 程 存在 一 个 致命 的 缺陷 ， 束 古 
SVN 的 补丁 文件 不 支持 二 进 制 文件 ， 因 此 采用 补丁 文件 的 方式 有 可 能 
丢失 数据 ， 如 新 增 或 修改 的 图 形 文 件 会 丢失 。 更 为 稳妥 但 也 更 为 复杂 
的 方式 可 能 要 用 到 svnadmin 命 令 将 版 本 库 导 出 。 命 令 如 下 : 


$svnadmin dump--incremental-r2:HEAD\ 
/path/to/repos/project1/>hacks.dump 


将 svnadmin 命 令 创建 的 导出 文件 恢复 到 版 本 库 中 也 非常 具有 挑战 
性 ， 这 里 束 不 再 详细 说 明了 。 还 古来 看 看 Git 在 这 种 情况 下 的 表现 吧 。 


2.Git 的 解决 方案 


与 SVN 将 产品 部 署 目录 转化 为 SVN 的 工作 区 相 比 ，Git 要 更 为 简 
单 ， 而 且 使 用 Git 导 出 提交 历史 也 更 为 简单 和 实用 ， 具 体操 作 过 程 如 
下 。 


(1) 创建 现场 版 本 库 。 直 接 在 需要 版 本 控制 的 目录 下 执行 Git 版 
本 库 初始 化 命令 。 


$git init 


(2) 添加 文件 并 提交 。 


$git add-A 
$git commit-m "initialized" 


(3) 为 初始 提交 建立 一 个 里 程 碑 : "v1" 。 


$git tag v1 


(4) 开始 在 工作 区 中 工作 一 修改 文件 并 提交 。 


$git commit-a 


(5) 当 对 修改 结果 满意 并 想 将 工作 成 果 保存 带 走 时 ， 可 以 通过 下 
面 的 命令 将 从 v1 开始 的 历次 提交 逐一 导出 为 补丁 文件 。 转 换 的 补丁 文 
件 部 包含 一 个 数字 前 级 ， 并 提取 提交 日 志 信 息 作为 文件 名 ， 而 且 补 丁 


文件 还 提供 对 二 进 制 文件 的 文 择 。 下 面 命 令 的 输出 摘 目 本 书 第 3 篇 第 20 
章 中 的 实例 。 

$git format-patch Vv1L. .HEAD 

0001-Fix-typo-help-to-help.patch 


0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 


(6) 通过 邮件 将 补丁 文件 发 出 。 当 然 ， 也 可 以 通过 其 他 方式 将 补 
了 丁 文件 市 走 。 


$git send-email*.patch 


Git 创 建 的 补丁 文件 使 用 了 Git 扩 展 格式 ， 因 此 在 导入 时 为 了 避免 
数据 遗漏 ， 要 使 用 Git 提 供 的 命令 而 不 能 使 用 GNU 的 patch 命 令 。 即 使 
要 导入 的 不 是 Git 版 本 库 ， 也 可 以 使 用 Git 命 令 ， 具 体操 作 请 参见 本 书 
第 7 篇 第 38 章 中 的 相关 内 容 。 


2.4 避 仑 引入 辅助 目 永 


很 多 版 本 控制 系统 都 要 在 工作 区 中 引入 辅助 目 隶 或 文件 ， 如 SVN 
要 在 工作 区 的 每 一 个 子 目 了 永 下 都 创建 .svn 目 未 ，CVS 要 在 工作 区 的 每 
一 个 子 目 孙 下 都 创建 CVS 目 孙 。 


这 些 辅助 目录 如 琳 出 现在 服务 器 上 ， 尤 其 是 Web 服 务 器 上 古 非 常 
危险 的 ， 因 为 这 些 辅助 目录 下 的 Entries 文 件 会 暴露 出 目录 下 的 文件 列 
表 ， 让 管理 员 精 心 配置 的 禁止 目录 浏览 的 努力 全 部 日 费 。 


还 有 ，SVN 的 .svn 辅 助 目录 下 还 存在 文件 的 原始 拷贝 ， 在 文件 搜 
索 时 结果 会 加 倍 。 如 果 你 曾经 在 SVN 的 工作 区 用 过 grep 命 令 进 行内 容 
查找 ， 台 会 明日 我 指 的 是 什么 。 


Git 没 有 这 个 问题 ， 不 会 在 子 目录 下 引入 讨厌 的 辅助 目录 或 文件 
Lgitignore 和 .gitattributes 文 件 不 算 ) 。 当 然 ，Git 还 是 要 在 工作 区 的 顶 
级 目录 下 创建 名 为 .git 的 目录 (版 本 库 目 录 ) ， 不 过 ， 如 果 你 认为 唯一 
的 一 个 .git 目 录 也 过 于 碍 上 腿 ， 可 以 将 其 放 到 工作 区 之 外 的 任意 目录 。 一 
旦 这 么 做 了 ， 在 执行 Git 命 令 时 ， 就 要 通过 命令 行 (--git-dir) 或 环境 变 
量 GIT_DIR 为 工作 区 指定 版 本 库 目 录 ， 甚 至 还 要 指定 工作 区 目录 。 


Git 还 专门 提供 了 一 个 git grep 命 令 ， 这 样 在 工作 区 根 目录 下 执行 查 
找 时 ， 目 录 .git 也 不 会 对 搜索 造成 影响 。 


天 于 辅助 目 永 的 详细 讨论 请 参见 本 书 第 2 篇 第 4.2 节 中 的 内 容 。 


2.5 重 写 提交 说 明 


很 多 人 可 能 像 我 一 样 ， 在 敲 下 回 车 之 后 才 发 现 提 交 说 明 中 有 错 别 
， 或 忘记 了 写 关联 的 Bug ID， 此 时 就 需要 重 写 提 交 说 明 。 


二 


1.SVN 的 解决 方案 


在 默认 情况 下 ，SVN 的 提交 说 明 是 禁止 更 改 的 ， 因 为 SVN 的 提交 
说 明 属 于 不 受 版 本 控制 的 属性 ， 一 旦 修改 就 不 可 恢复 。 我 建议 SVN 的 
管理 员 只 有 在 配置 了 版 本 库 更 改 的 外 发 邮件 通知 之 后 ， 再 开放 提交 说 
明 更 改 的 功能 。 我 发 布 于 SourceForge 上 的 pySvnManager 项 目 提供 了 
SVN 版 本 库 图 形 化 的 钩子 管理 ， 会 简化 管理 员 的 配置 工作 。 


即使 SVN 管 理 员 局 用 了 人 允许 更 改 提交 说 明 的 设置 ， 修 改 提交 说 明 
也 还 是 挺 复杂 的 ， 看 看 下 面 的 命令 : 


$svn ps--revprop-r<REV>Svn:1og "new log message..." 


2.Git 的 解决 方案 


Git 修 改 提 交 说 明 很 位 单 ， 而 且 提 交 说 明 的 修改 也 是 被 仍 踩 的 。 
Git 修 改 最 新 提交 的 提交 说 明 最 为 简单 ， 使 用 一 条 名 为 修补 提交 的 命令 
印 可 。 


$git commit--amend 


这 个 命令 如 条 不 市 -m 参 数 ， 会 进入 提交 说 明 编 辑 界面 ， 修 改 原 来 
的 提交 说 明 ， 直 到 满意 为 止 。 


如 果 要 修改 某 个 历史 提交 的 提交 说 明 ，Git 也 可 以 实现 ， 但 要 用 到 
男 外 一 个 命令 ， 变 基 命 令 。 例 如 ， 要 修改 <commit-id> 所 标识 的 提交 
的 提交 说 明 ， 执 行 下 面 的 命令 ， 并 在 弹出 的 变 基 索引 文件 中 修改 相应 
提交 前 面 的 动作 的 关键 子 。 


$git rebase-i<commit-id> 人 ^ 


关于 如 何 使 用 交互 式 变 基 操 作 更 改 历史 提交 的 提交 说 明 ， 请 参见 
本 书 第 2 篇 第 12 章 中 的 内 容 。 


2.6” 想 吃 后 悔 药 


假如 提交 的 数据 中 不 小 心包 含 了 一 个 不 应 该 检 入 的 虚拟 机 文件 
一 大 约 有 1 个 GB1! 这 时 候 ， 您 会 多 么 希望 这 个 世界 上 有 后 悔 药 卖 


啊 。 
1.SVN 的 解决 方案 


SVN 遇 到 这 个 问题 该 怎么 办 呢 ? 删除 错误 加 入 的 大 文件 后 再 提 
交 ， 这 样 的 操作 古 不 能 解决 问题 的 。 虽 然 表 面 上 去 挥 了 这 个 文件 ,但 
是 它 依 然 存 在 于 历史 中 。 


管理 员 可 能 十 受 影 啊 最 大 的 人 ， 因 为 他 要 人 负 员 管理 服务 右 的 磁 副 
空间 占用 及 版 本 库 的 备份 。 实 际 上 这 个 问题 也 只 有 管理 员 才 能 解决 ， 
所 以 你 必须 同 管理 员 坦 白 ， 让 他 帮 你 在 服务 紫 病 彻 瓜 删除 错误 引入 的 
大 文件 。 我 要 告诉 你 的 是 ， 对 于 管理 员 ， 这 并 不 是 一 个 简单 的 活 。 


(1) 如 果 SVN 管 理 员 没有 历史 备份 ， 只 能 重新 用 svnadmin dump 
导出 整个 版 本 库 。 


(2) 再 用 svndumptfilter 命 令 过 滤 掉 不 应 检 入 的 大 文件 。 


(3) 然后 用 svnadmin load 重 建 版 本 库 。 


上 面 的 操作 描述 中 省 略 了 一 些 窍门 ， 如 果 要 把 窍门 讲 清楚 ， 这 本 
书 就 不 是 讲 Git， 而 是 讲 SVN 了 ， 故 本 书 中 不 进行 深入 探讨 。 


2.Git 的 解决 方案 


如 采 你 用 Git， 一 切 融会 变 得 非常 简单 ， 而 且 你 也 不 必 去 乞求 管理 
， 因 为 使 用 Git， 每 个 人 都 是 管理 员 。 


il 


如 果 是 最 新 的 提交 引入 了 不 该 提交 的 大 文件 ，winxp.img， 操 作 起 
来 会 非常 位 单 ， 还 十 用 修补 提交 命令 。 


$git rm--cached winxp.img 
$git commit--amend 


如 果 是 历史 版 本 ， 例 如 是 在 <commit-id> 所 标识 的 提交 中 引入 的 
文件 ， 则 需要 使 用 变 基 操作 。 


$git rebase-i<commit-id> 人 ^ 


执行 交互 式 变 基 操作 抛弃 历史 提交 ， 版 本 库 还 不 能 立即 瘦 映 ， 具 
体 原 因 和 解决 方案 请 参见 本 书 第 2 篇 第 14 章 中 的 内 容 。 除 了 使 用 变 基 操 
作 ，Git 还 有 更 多 的 武器 可 以 实现 版 本 库 的 整理 操作 ， 具 体 请 参见 本 书 
第 6 篇 第 35.4 节 的 内 容 。 


2.7 更 好 用 的 提交 列表 


正确 的 版 本 控制 系统 的 使 用 方法 是 ， 一 次 提交 只 干 一 件 事 : 或 是 
完成 了 一 个 新 功能 ， 或 是 修改 了 一 个 Bug、 或 是 写 完了 一 节 的 内 容 ， 
或 是 添 加 了 一 幅 图 片 ， 束 执行 一 次 提交 。 不 要 在 下 班 时 才 想 起 来 要 所 
交 ， 那 样 的 话 版 本 控制 系统 束 补 降格 为 文件 备份 系统 


但 有 了 时 在 同一 个 工作 区 中 可 能 要 同时 做 两 件 事情 ， 一 个 是 尚未 完 
成 的 新 功能 ， 男 外 一 个 是 解决 刚刚 发 现 的 Bug。 很 多 版 本 控制 系统 没 
有 提交 列表 的 概念 ， 要 么 需要 在 命令 行 中 指定 要 提交 的 文件 ， 要 么 默 
认 把 所 有 修改 内 容 全 部 提交 ， 破 坏 了 一 次 提交 只 干 一 件 事 的 原则 。 


1.SVN 的 解决 方案 


SVN 1.5 开 始 提供 变更 列表 (change list) 的 功能 ， 是 通过 引入 一 
个 狐 的 命令 svn changelist 来 实现 的 。 但 是 我 从 来 就 没有 真正 用 过 ， 
为 : 


定义 一 个 变更 列表 太 麻 烦 。 例 如 ， 没 有 一 个 快捷 命令 将 当前 所 有 
改动 的 文件 加 入 列表 ， 也 没有 快捷 命令 将 工作 区 中 的 新 文件 全 部 加 入 
列 及 


一 个 文件 不 能 同时 属于 两 个 变更 列表 。 两 次 变更 不 许 有 文件 交 
又 ， 这 样 的 限制 不 合理 。 


变更 列表 是 一 次 性 的 ， 提 交 之 后 目 动 消 失 。 这 样 的 设计 没有 问 
题 ， 但 是 相 比 定义 列表 时 的 壹 瑛 ， 以 及 提交 时 必须 指定 列表 的 党 琐 ， 
使 用 变更 列表 未 人 免得 不 偿 失 。 


因为 Subversion 的 提交 不 能 撤销 ， 如 末 在 提交 时 起 了 提供 变更 列表 
名 称 以 针对 特定 的 变更 列表 进行 提交 ， 错 认 的 提交 内 容 将 无 法 补救 。 


总 之 ，SVN 的 变更 列表 尚 不 如 鸡肋 ， 食 之 无 味 ， 弃 之 不 可 惜 。 


2.Git 的 解决 方案 


Git 通 过 提交 和 暂 存 区 实现 对 提交 内 容 的 定制 ， 非 常 完美 地 实现 了 对 
工作 区 的 修改 内 容 进 行径 选 提交 : 


执行 git add 命 令 将 修改 内 容 加 入 提交 暂 存 区 。 执 行 git add-u 命 令 可 
以 将 所 有 修改 过 的 文件 加 入 暂 存 区 ， 执 行 git add-A 命 令 可 以 将 本 地 删 
除 文件 和 新 增 文件 都 登记 到 提交 和 暂 存 区 ， 执 行 git add-p 命 令 甚 至 可 以 
对 一 个 文件 内 的 修改 进行 有 选择 性 的 添加 。 


一 个 修改 后 的 文件 被 登记 到 提交 和 暂 存 区 后 ， 可 以 继续 修改 ， 继 续 
修改 的 内 容 不 会 补 提 交 ， 除 非 对 此 文件 再 执行 一 次 git add 命 令 。 即 一 


个 修改 的 文件 可 以 拥有 两 个 版 本 ， 在 提交 暂 存 区 中 有 一 个 版 本 ， 在 工 
作 区 中 有 另外 一 个 版 本 。 

执行 git commit 命 令 提 交 ， 无 须 设 定 变更 列表 ， 直 接 将 登记 在 暂 存 
区 中 的 内 容 提交 。 


Git 文 持 撤 销 提 交 ， 而 且 可 以 撤销 任意 多 次 。 


只 要 使 用 Git， 丈 会 时 刻 与 隐形 的 提交 列表 打交道 。 本 书 第 2 篇 第 5 


章 会 详细 介绍 Git 的 这 一 特性 ， 相 信 你 会 爱 上 Git 的 这 个 特性 。 


2.8 更 好 的 老 异 比较 


Git 对 差异 比较 进行 了 扩展 ， 支 持 对 二 进 制 文件 的 差异 比较 ， 这 是 
对 GNU 的 diff 和 patch 命 令 的 重要 补充 。 而 且 Git 的 差异 比较 除了 文 持 基 
于 行 的 差异 比较 外 ， 还 支持 在 一 行内 逐 字 比较 的 方式 ， 当 向 git diff 命 
令 传递 --word-diff 参 数 时 ， 就 会 进行 逐 字 比较 。 


上 面 介 绍 了 工作 区 的 文件 修改 可 能 会 有 两 个 不 同 的 版 本 : 一 个 在 
提交 暂 存 区 ， 一 个 在 工作 区 。 因 此 ， 在 执行 git diff 命 令 时 会 遇 到 令 Git 
新 手 费 解 的 现象 。 


修改 后 的 文件 在 执行 git diff 命 令 时 会 看 到 修改 造成 的 差异 。 


修改 后 的 文件 通过 git add 命 令 提 交 到 暂 存 区 后 ， 再 执行 git diff 命 令 
将 看 不 到 该 文件 的 差异 。 


继续 对 此 文件 进行 修改 ， 再 次 执行 git diff 命 令 会 看 到 新 的 修改 显 
示 在 老 异 中 ， 而 看 不 到 旧 的 修改 。 


执行 git diff--cached 命 令 才 可 以 看 到 添加 到 暂 存 区 中 的 文件 所 做 出 
的 修改 。 


Git 震 异 比较 的 命令 充满 了 魔法 ， 本 书 第 5.3 世 会 市 您 破解 Git 的 diff 
魔法 。 一 旦 您 习惯 了 ， 丈 会 非常 喜欢 git diff 的 这 个 行为 。 


2.9 工作 进度 保存 


如 果 在 工作 区 的 修改 尚未 完成 时 名 然 有 一 个 紧急 的 任务 ， 需 要 从 
一 个 干净 的 工作 区 开始 新 的 工作 ， 或 要 切换 到 别 的 分 文 进行 工作 ， 那 
么 如 何 保存 当前 尚未 完成 的 工作 进度 呢 ? 


1.SVN 的 解决 方案 


如 果 版 本 库 规模 不 大 ， 最 好 重新 检 出 一 个 新 的 工作 区 ， 在 新 的 工 
作 区 进行 工作 。 否 则 ， 可 以 执行 下 面 的 操作 。 


$svn diff>/path/to/saved/patch.file 
$svn revert-R 
$svn switch<new branch> 


在 新 的 分 文中 工作 完毕 后 ， 再 切换 回 当 前 分 文 ， 将 补丁 文件 重新 
应 用 到 工作 区 。 


$svn Switch<original_branch > 
$patch-p1</path/to/saved/patch.file 


但 是 切记 SVN 的 补丁 文件 不 支持 二 进 制 文件 ， 这 种 操作 方法 可 能 
会 丢失 对 二 进 制 文件 的 更 改 ! 


2.Git 的 解决 方案 


Git 提 供 了 一 个 可 以 保存 和 恢复 工作 进度 的 命令 git stash。 这 个 命 
令 非 常 方便 地 解决 了 这 个 难题 。 

在 切换 到 新 的 工作 分 支 之 前 执行 git stash 保 存 工作 进度 ， 工 作 区 就 
会 变 得 非常 干将， 然后 就 可 以 切换 到 新 的 分 文中 了 。 


$git stash 
$git checkout<new_branch > 


新 的 工作 分 文 修改 完毕 后 ， 再 切换 回 当 前 分 文 ， 调 用 git stash pop 
命令 则 可 恢复 之 前 保存 的 工作 进度 。 


$git checkout<orignal_branch > 
$git stash pop 


本 书 第 2 篇 第 9 章 会 为 您 揭 开 git stash 命 令 的 奥秘 。 


2.10 代理 SVN 提 区 实现 移动 式 办 公 


使 用 像 SVN 一 样 的 集中 式 版 本 控制 系统 ， 要 求 使 用 者 和 版 本 控制 
服务 颖 之 间 要 有 网 络 连接 ， 如 末 因 为 出 差 在 外 或 在 家 办 公 访 问 不 到 版 
本 控制 服务 器 束 无 法 提交 。Git 属 于 分 布 式 版 本 控制 系统 ， 不 存在 这 样 


的 问题 。 


当 版 本 控制 服务 器 无 法 实现 从 SVN 到 Git 的 迁移 时 ， 仍 然 可 以 使 用 
Git 进 行 工 作 。 在 这 种 情况 下 ，Git 作 为 客户 端 来 操作 SVN 服 务 右 ， 实 
现在 移动 办 公 状 态 下 的 版 本 提交 (当然 是 在 本 地 Git 库 中 提交 ) 。 当 能 
够 连通 SVN 服 务 器 时 ， 一 次 性 将 移动 办 公 状 态 下 的 本 地 提交 同步 到 
SVN 服 务 器 。 整 个 过 程 对 于 SVN 来 说 是 透明 的 ， 没 有 人 知道 你 是 使 用 


Git 在 进行 提交 。 
使 用 Git 来 操作 SVN 版 本 控制 服务 器 的 一 般 工 作 流程 为 : 


(1) 访问 SVN 服 务 器 ， 将 SVN 版 本 库 克 隆 为 一 个 本 地 的 Git 库 ， 
一 个 货真价实 的 Git 库 ， 不 过 其 中 包含 针对 SVN 的 扩展 。 


$git svn clone<svn_repos_uril> 


(2) 使 用 Git 命 令 操作 本 地 克隆 的 版 本 库 ， 例 如 提交 就 使 用 git 


commit 命 令 。 


(3) 当 能 够 通过 网 络 连 接 到 SVN 服 务 器 ， 并 想 将 本 地 提交 同步 到 
SVN 服 务 器 时 ， 移 获取 SVN 服 务 器 上 最 新 的 提交 ， 然 后 执行 变 基 操 
作 ， 最 后 再 将 本 地 提交 推送 给 SVN 服 务 器 


$git svn fetch 
$git svn rebase 
$git svn dcommit 


本 书 第 4 篇 第 26 章 会 详细 介绍 这 一 话题 。 


2.11 无 处 不 在 的 分 页 规 


虽然 拥有 图 形 化 的 客户 端 ， 但 Git 的 主要 操作 还 是 以 命令 行 的 方式 
完成 的 。 使 用 命令 行 方式 的 好 处 一 个 十 快 ， 男 外 一 个 是 可 以 防止 姐 标 
手 的 出 现 。Git 的 命令 行 加 入 了 大 量 的 人 性 化 设计 ， 包 括 命 令 补 全 、 彩 
色 字 符 输出 中 等 ， 不 过 最 具 特 色 的 还 是 无 处 不 在 的 分 页 器 。 


在 操作 其 他 版 本 控制 系统 的 命令 行 时 ， 如 果 命 令 的 输出 超过 了 一 
屏 ， 为 了 能 够 逐 屏 显示 ， 需 要 在 命令 的 后 面 加 上 一 个 管道 符号 将 输出 


交 给 一 个 分 页 右 。 例 如 : 


可 


什 


$svn log|less 


而 Git 则 不 用 如 此 麻烦 ， 因 为 每 个 Git 命 令 目 动 这 有 一 个 分 页 右 ， 
默认 使 用 less 命 令 (less-FRSX) 进行 分 页 。 当 一 屏 显 示 不 下 时 局 动 分 
页 器， 这 个 分 页 器 文 持 市 颜色 的 字符 输出 ， 对 于 太 长 的 行 则 采用 截断 
方式 处 理 。 因 为 less 分 页 器 在 翻 屏 时 使 用 了 vi 风格 的 热 键 ， 如 有 果 您 不 熟 
悉 vi 的 话 ， 可 能 会 遇 到 麻 焕 。 下 面 是 分 页 右 中 常用 的 热 刍 : 


按 空格 下 翻 一 页 ， 按 字母 b 上 翻 一 页 。 
字母 4 和 u:， 分 别 代表 向 下 翻动 半 页 和 向 上 翻动 半 页 。 
字母 j 和 k: 分 别 代表 向 上 翻 一 行 和 向 下 翻 一 行 。 


如 果 行 太 长 被 截断 ， 可 以 用 左 箭头 和 右 箭头 使 窗口 内 容 左右 深 


输入 /pattern: 回 下 寻找 和 pattern 匹 配 的 内 容 。 
输入 ?pattermn: 问 上 寻找 和 pattern 匹 配 的 内 容 。 
字母 n 或 N; 代表 问 前 或 向 后 继续 寻找 。 


字母 5， 跳 到 第 一 行 ， 字 母 G， 跳 到 最 后 一 行 ， 输 入 数字 再 加 字母 
g， 则 跳 转 到 对 应 的 行 。 


输入 !<command> : 可 以 执行 Shell 命 令 


如 果 不 习 惯 分 页 紫 的 长 行 截断 模式 而 希望 能 够 目 动 换行 ， 可 以 通 
过 设置 LESS 环 境 变量 来 实现 。LESS 环 境 变量 设置 如 下 : 


$export LESS=FRX 


或 者 使 用 Git 的 方式 ， 定义 Git 配 置 变 量 来 改变 分 页 絮 的 默认 
行为 。 例 如 设置 core.pager 配 置 变量 如 下 : 


$git config--global core.pager 'less-+$LESS-FRX' 


[1] 须 通过 Git 配 置 变量 启用 ， 如 运行 命令 : git config--global color.ui 


true 


2.12 快 


您 有 项 目 托管 在 sourceforge.net 的 CVS 或 SVN 服 务 器 上 人 么 ? 是 否 会 
为 公司 的 SVN 服 务 絮 部署 在 男 外 一 个 城市 而 需要 经 过 互联 网 才能 访 
问 ? 


使 用 传统 的 集中 式 版 本 控制 服务 器 时 ， 如 采 遇 到 上 面 的 情况 ， 而 
且 网 络 融 视 没 有 保证 ， 那 么 使 用 起 来 时 一 定 会 因为 速度 慢 而 让 人 痛苦 
不 堪 。Git 作 为 分 布 式 版 本 控制 系统 彻 瓜 解决 了 这 个 问题 ， 几 乎 所 有 的 
操作 都 在 本 地 进行 ， 而 且 速 度 还 不 是 一 般 的 快 。 


还 有 很 多 其 他 的 分 布 式 版 本 控制 系统 ， 如 Hg 和 Bazaar 等 ， 与 这 些 
分 布 式 版 本 控制 系统 相 比 ，Git 在 速度 上 也 有 优势 ， 这 得 益 于 Git 独 特 
的 版 本 库 设 计 。 第 2 篇 的 相关 章 让 会 辣 您 展示 Git 独 特 的 版 本 库 设 计 。 


其 他 很 多 的 版 本 控制 系统 ， 当 输入 检 出 、 更 新 或 克隆 等 命令 后 ， 
只 能 双手 合十 ， 然 后 望 眼 欲 军 ， 因 为 整个 操作 过 程 不 知道 什么 时 候 才 
能 够 完成 。 而 Git 在 版 本 库 殉 隆 及 与 版 本 库 同 步 的 时 候 ， 能 够 实时 地 显 
示 完 成 的 进度 ， 这 不 但 是 非常 人 性 化 的 设计 ， 更 体现 了 Git 的 智能 。 
Git 的 智能 协议 兰 目 于 会 话 过 程 中 在 客户 端 和 服务 闫 端 各 目 局 用 了 一 个 
会 话 的 角色 ， 用 于 按 需 传输 和 获取 进度 。 


第 3 革 ”Git 的 安 狠 和 使 用 


Git 源 目 Linux， 现 在 已 经 可 以 部 署 在 所 有 的 主流 平台 之 上 ， 包 括 
Linux、Mac OS X 和 Windows。 我 们 在 开始 Git 之 旅 之 前 ， 首 先 要 做 的 


束 是 安 狼 Git 。 


3.1 ”在 Linux 下 安装 和 使 用 Git 


Git 竹 生 于 Linux 平 台 并 作为 版 本 控制 系统 率先 服务 于 Linux 内 核 ， 
因此 在 Linux 上 安装 Git 征 非常 方便 的 。 可 以 通过 两 种 不 同 的 方式 在 
Linux 上 安装 Git: 一 种 方法 是 通过 Linux 发 行 版 的 包 管 理 器 安装 已 经 编 
译 好 的 二 进 制 格式 的 Git 软 件 包 ， 另 外 一 种 方式 就 是 从 Git 源 码 开始 安 


3.1.1 包 管 理 器 方式 安装 


用 Linux 发 行 版 的 包 管理 絮 安 装 Git 最 为 人 简单， 而 且 会 自动 配置 好 
命令 补 齐 等 功能 ， 但 安装 的 Git 可 能 不 是 最 新 的 版 本 。 还 有 一 点 要 注 
意 ，Git 软 件 包 在 有 的 Linux 发 行 版 中 可 能 不 叫 git， 而 叫 git-core。 这 是 
因为 有 一 款 名 为 GNU 交 互 工具 1 (GNU Interactive Tools) 的 GNU 软 
件 ， 在 Git 之 前 束 在 一 些 Linux 发 行 版 (Deian lenny) 中 占用 了 git 这 个 


名 称 。 为 了 以 示 区 分 ， 作 为 版 本 控制 系统 的 Git， 其 软件 包 在 这 些 平台 
就 被 命名 为 git-core。 不 过 ， 因 为 作为 版 本 控制 系统 的 Git 太 有 名 了 ， 所 
以 一 些 Linux 发 行 版 在 最 新 的 版 本 中 将 GNU Interactive Tools 软 件 包 的 
名 称 由 git 改 为 了 gnuit， 将 git-core 改 为 了 git。 因 此 在 下 面 介 绍 的 在 不 同 
的 Linux 发 行 版 中 安装 Git 时 ， 会 看 到 有 git 和 git-core 两 个 不 同 的 名 称 。 


Ubuntu 10.10 (maverick) 或 更 新 的 版 本 、Debian (squeeze) 或 更 
新 的 版 本 : 


$sudo aptitude install git 
$sudo aptitude install git-doc git-svn git-email git-gui gitk 


其 中 git 软 件 包 包 舍 了 大 部 分 Git 命 令 ， 是 必 帮 的 软件 包 。 


软件 包 git-svn、git-email、git-gui、gitk 本 来 也 是 Git 软 件 包 的 一 部 
分 , 但 是 因为 有 着 不 一 样 的 软件 包 依 赖 《如 更 多 的 perl 模 组 和 全 等 ) ， 
所 以 单独 作为 软件 包 发 布 。 


软件 包 git-doc 则 包含 了 Git 的 HTML 格 式 文档 ， 可 以 选择 安装 。 如 
果 安 装 了 了 Git 的 HTML 格 式 的 文档 ， 则 可 以 通过 执行 git help-w < sub- 
command> 命令 来 目 动用 Web 浏 览 囊 打开 相关 了 命令 < sub-command > 
的 HTML 帮 助 。 


Ubuntu 10.04 (lucid) 或 更 老 的 版 本 、Debian (lenny) 或 更 老 的 
版 本 : 


在 老 版 本 的 Debian 中 ， 软 件 包 git 实 际 上 是 指 GNU Interactive 
Tools， 而 非 作为 版 本 控制 系统 的 Git。 作 为 版 本 控制 系统 的 Git 在 软件 
包 git-core 中 。 


$sudo aptitude install git-core 
$sudo aptitude install git-doc git-svn git-email]l git-gui gitk 


RHEL ~ Fedora 、 CentOsS: 


$yum install git 
$yum install git-svn git-email git-gui gitk 


在 其 他 发 行 版 中 安装 Git 的 过 程 和 上 面 介绍 的 方法 类 似 。Git 软 件 
包 在 这 些 发 行 版 里 或 称 为 git， 或 称 为 git-core 。 


[1| http:/www.gnu.org/software/gnuit/ 


3.1.2 ”从 源 代 码 进行 安装 
访问 Git 的 官方 网 站 : http://git-scm.com/。 下载 Git 源 码 包 ， 例 如 : 
git-1.7.4.1.tarbz2 上 。 安 装 过 程 如 下 : 
(1) 展开 源码 包 ， 并 进入 到 相应 的 目录 中 。 


$tar-jxvf git-1.7.4.1.tar.bz2 
$cd git-1.7.4.1/ 


(2) 安装 方法 写 在 INSTALL 文 件 中 ， 参 照 其 中 的 指示 即 可 完成 
安装 。 下 面 的 命令 将 Git 安 装 在 /usr/local/bin 中 。 


$make prefix=/usr/local all 
$sudo make prefix=/usr/local install 


(3) 安装 Git 文 档 (可 选 ) 。 


编译 的 文档 主要 是 HTML 格 式 的 文档 ， 方 便 通 过 git help-w < sub- 
command> 命令 查看 。 实 际 上 ， 即 使 不 安装 Git 文 档 ， 也 可 以 使 用 man 
手册 查看 Git 帮 助 ， 使 用 命令 git heljp< sub-command > 或 git< sub- 
command> --help 即 可 。 


编译 文档 依赖 asciidoc， 因 此 需要 先 安装 asciidoc (如 果 尚 未 安装 
的 话 ) ， 然 后 编译 文档 。 在 编译 文档 时 要 花费 很 多 时 间 ， 要 有 了 耐心 。 


$make prefix=/usr/local doc info 
$sudo make prefix=/usr/local install-doc install-html install- 
info 


安装 完毕 之 后 ， 就 可 以 在 /usr/local/bin 下 找到 git 命 令 。 


[1] 在 你 下 载 的 时 候 可 能 已 经 有 了 更 新 的 版 本 。 


3.1.3” 从 Git 版 本 库 进 行 安 装 


如 果 在 本 地 克隆 一 个 Git 项 目的 版 本 库 ， 束 可 以 用 版 本 库 同步 的 方 
式 获取 最 新 版 本 的 Git， 这 样 在 下 载 不 同 版 本 的 Git 源 代码 时 实际 上 采 
用 了 增 量 方式 ， 非 常 节 省 时 间 和 空间 。 当 然 使 用 这 种 方法 的 前 提 古 已 
经 用 其 他 方法 安装 好 了 Git， 具 体操 作 过 程 如 下 。 


(1) 克隆 Git 项 目的 版 本 库 到 本 地 。 


$git clone git://git,.kernel.org/pub/scm/git/git.git 
$cd git 


(2) 如 果 本 地 已 经 元 隆 过 一 个 Git 项 目的 版 本 库 ， 直 接 在 工作 区 
中 更 新 ， 以 获得 最 新 版 本 的 Git。 


$git fetch 


(3) 执行 清理 工作 ， 避 免 前 一 次 编译 的 遗留 文件 对 编译 造成 影 
啊 。 注 意 ， 下 面 的 操作 将 丢弃 本 地 对 Git 代 码 的 改动 。 


$git clean-fdx 
$git reset--hard 


(4) 查看 Git 的 里 程 碑 ， 选 择 最 新 的 版 本 进行 安装 ， 例 如 
V1.7.4.1。 


$git tag 


V1.7.4.1 


(5) 检 出 该 版 本 的 代码 。 


$git checkout v1i.7.4.1 


(6) 执行 安装 。 例 如 ， 安 装 到 /usr/local 目 录 下 。 


$make prefix=/usr/local all doc info 
$sudo make prefix=/usr/local install\ 
install-doc install-html] install-info 


我 在 所 写本 书 的 过 程 中 ， 束 是 通过 Git 版 本 库 的 方式 安装 的 ， 
在 /opt/git 目 好 下 安 狼 了 多 个 不 同 版 本 的 Git， 以 测试 Git 的 兼容 性 。 可 以 
使 用 类 似 下 面 的 脚本 来 批量 安装 不 同 版 本 的 Git 。 


#!/bin/sh 

for ver in\ 

V1.5.0\ 

V1.7.3.5\ 

V1.7.4.1\ 

; do 

echo "Begin install Git$ver."; 

git reset--hard 

git clean-fdx 

git checkout$ver||t{ 

echo "Checkout git$ver failed."; exit 1 
} 

make prefix=/opt/git/$ver all&&\ 

sudo make prefix=/opt/git/$ver install||{ 
echo "Install git$ver failed."; exit 1 


} 
echo "Installed Git$ver." 


done 


3.1.4 ”命令 补 齐 


Linux 的 shell 环 境 (bash) 通过 bash-completion 软 件 包 提供 命令 补 
齐 功 能 ， 在 录入 命令 参数 时 按 一 次 或 两 次 TAB 键 可 实现 参数 的 自动 补 
齐 或 提示 。 例 如 输入 git com 后 按 下 TAB 键 ， 会 目 动 补 齐 为 git commit 。 


如 果 通 过 包 管 理 器 方式 安装 Git， 一 般 都 已 经 为 Git 配 置 好 了 自动 
什 齐 ， 但 是 如 果 是 以 源码 编译 的 方式 安装 Git， 就 需要 为 命令 补 齐 多 做 
些 工 作 ， 具 体操 作 过 程 如 下 。 

(1) 将 Git 源 码 包 中 的 命令 补 齐 脚本 复制 到 bash-completion 对 应 的 
目录 中 。 


$cp contrib/completion/git-completion.bash\ 
/etc/bash_ completion.d/ 


(2) 重新 加 载 自动 补 齐 脚本 ， 使 之 在 当前 的 shell 中 生效 。 


$./etc/bash_completion 


(3) 为 了 能 够 在 终端 开启 时 上 自动 加 载 bash_completion 脚 本 ， 需 要 
在 系统 配置 文件 /etc/profile 0 及 本 地 配置 文件 ~/bashrc 2 中 添加 下 面 
的 内 容 。 


if[-f/etc/bash_completion];then 
/etc/bash_completion 
fi 


[1] 配置 文件 /etc/profile 及 ~/.bash_profile、~/.profile 等 作用 于 交互 式 登 
录 shell 。 

[2] 配置 文件 ~/.bashrc 作 用 于 交互 式 非 登录 shell， 如 screen 或 byobu 中 建 
立 的 新 的 shell 窗 口 。 


3.1.5 “中文 文 持 


Git 的 本 地 化 做 得 并 不 完善 ， 命 令 的 输出 及 命令 的 帮助 还 只 能 输出 
英文 ， 也 许 在 未 来 的 版 本 中 会 使 用 gettext 实 现 本 地 化 ， 束 和 像 目前 对 git- 
gui 命 令 所 做 的 那样 。 


中 文 用 户 最 关心 的 问题 还 有 : 是 否 可 以 在 提交 说 明 中 使 用 中 文 ? 
是 否 可 以 使 用 中 文 文件 名 或 目录 名 ? 是 否 可 以 使 用 中 文 来 命名 分 支 或 
里 程 碑 ? 简单 地 说 ， 可 以 在 提交 说 明 中 使 用 中 文 ， 但 是 需要 对 Git 进 行 
设置 。 人 至 于 用 中 文 来 命名 文件 、 目 录 和 引用 ， 只 有 在 使 用 UTF-8 字 符 
集 的 环境 下 (Linux、Mac OS X、Windows 下 的 Cygwin) 才 可 以 ， 否 
则 应 尽量 避免 使 用 。 


1.UTF-8 字 符 集 


Linux 平 台 的 中 文 用 户 一 般 会 使 用 UTF-8 字 符 集 ，Git 在 UTF-8 字 符 


集 下 可 以 工作 得 非 第 好 : 


在 提交 时 ， 可 以 在 提交 说 明 中 输入 中 文 。 


显示 提交 历史 ， 能 够 正 第 显示 提交 说 明 中 的 中 文字 符 。 


可 以 添加 名 称 为 中 文 的 文件 ， 并 可 以 在 同样 使 用 UTF-8 字 符 集 的 
Linux 环 境 中 克隆 和 检 出 。 


可 以 创建 市 有 中 文字 符 的 里 程 牧 名 称 。 


但 是 ， 在 默认 设置 下 ， 中 文 文件 名 在 工作 区 状态 输出 、 查 看 历史 
更 改 概 要 ， 以 及 在 补丁 文件 中 ， 文 件 名 中 的 中 文 不 能 正确 地 显示 ， 而 
征 显示 为 八进制 的 字符 编码 ， 如 下 : 


$git status-s 

?7 "\350\257\264\346\230\216.txt" 
$printf "\350\257\264\346\230\216.txt\n" 
说 明 ,txXt 


过 将 Git 配 置 变量 core.quotepath 设 置 为 false， 就 可 以 解决 中 文 文 
件 名 在 这 些 Git 命 令 输出 中 的 显示 问题 。 
$git config--global core.quotepath false 


$git status-s 
?2 说 明 .txt 


如 果 Linux 平 台 采 用 非 UTF-8 的 字符 集 ， 例 如 ， 用 zh_CN.GBK 字 符 
集 编 码 《有 人 这 么 做 吗 ? ) ， 就 要 另外 再 做 些 工 作 了 。 


将 显示 提交 说 明 所 使 用 的 字符 集 设置 为 gbk， 这 样 使 用 git 1og 查 看 
提交 说 明 时 才能 够 正确 显示 其 中 的 中 文 。 


$git config--global i1i8n.logOutputEncoding gbk 


设置 录入 提交 说 明 时 所 使 用 的 字符 集 ， 以 便 在 commit 对 象 中 正确 
标注 字符 集 。Git 在 提交 时 并 不 会 对 提交 说 明 进 行 从 GBK 字 符 集 到 
UTF-8 的 转换 ， 但 是 可 以 在 提交 说 明 中 标注 所 使 用 的 字符 集 ， 因 此 在 
韭 UTF-8 字 符 集 的 平台 中 录入 中 文 时 需要 用 下 面 的 指令 设置 录入 提交 
说 明 的 字符 集 ， 以 便 在 commit 对 象 中 舱 入 正确 的 编码 说 明 。 


$git config--global 1I18n.commitEncoding gbk 


3.2 ”在 Mac OS X 下 安装 和 使 用 Git 


Mac OS X 被 称 为 最 人 性 化 的 操作 系统 之 一 ， 工 作 在 Mac 上 十 件 非 
常 慨 意 的 事情 ， 工 作 中 又 怎 能 没有 Git 呢 ? 


3.2.1 ”以 二 进 制 发 布 包 的 方式 安装 


Git 在 Mac OS X 中 也 有 好 几 种 安 洲 方 法 。 最 简单 的 方式 钙 安 
淡 .dmg 格 式 的 安装 包 。 


访问 git-osx-installer 的 官方 网 站 : http://code.google.com/p/git-osx- 
installer/， 下 载 Git 安 装 包 。 安 涛 包 带 有 .dmg 扩 展 名 ， 是 苹果 磁 表 镜 像 
(Apple Disk Image) 格式 的 软件 发 布 包 。 从 官方 网 站 上 下 载 文件 名 格 
式 为 gitt<version>-< arch> -leopard.dmg 的 安装 包 文 件 ， 例 如 : git- 


1.7.4-x86_64-leopard.dmg 是 64 位 的 安装 包 ，git-1.7.4-i386-leopard.dmg 
是 32 位 的 安装 包 。 建 议 选 择 64 位 的 软件 包 ， 因 为 Mac OS X 10.6 ( 雪 
豹 ) 完美 地 兼容 32 位 和 64 位 〈 开 机 按 住 键 盘 数 字 3 和 2 进入 32 位 系统 ， 
按 住 6 和 4 进入 64 位 系统 ) ， 即 使 内 核 的 架构 是 32 位 的 ， 也 可 以 放心 地 


运行 64 位 的 软件 包 。 


芋 条 的 .dmg 格 式 的 软件 包 实 际 上 十 一 个 磁盘 映像 ， 安 半 起 来 非常 
方便 ， 点 击 该 文件 束 可 以 直接 挂 载 到 Finder 中 ， 打 开 后 如 图 3-1 所 示 。 


SHELL 


setup git PATH for non- 
" terminal programs,sh 


3-1 在 Mac OS X 下 打开 .dmg 格 式 人 磁盘 镜像 


图 3-1 中 显示 为 拆 包 图 标的 文件 (扩展 名 为 .pkg) 就 是 Git 的 安装 程 
序 ， 另 外 的 两 个 脚本 程序 ， 一 个 用 于 应 用 的 御 载 (uninstall.sh) ， 另 
外 一 个 带 有 长 文件 名 的 脚本 在 Git 安 装 后 再 执行 ， 为 非 终端 应 用 注册 
Git 的 安装 路 径 ， 这 是 因为 Git 部 署 在 标准 的 系统 路 径 之 
gh/usr/local/git/bin 。 


点 击 扩展 名 为 .pkg 的 安装 程序 ， 开 始 Git 的 安装 (以 安装 Git1.7.3.5 
版 本 为 例 ) ,根据 提示 按 步 又 完成 安装 ， 如 图 3-2 所 示 。 


欢迎 使 用 "Git 1.7.3.5 x86_64" 安 装 器 


安装 器 将 引 等 您 完成 安装 信 软 件 所 鸯 要 的 步 独 。 


3-2 在 Mac OS X 下 安装 Git 


安装 完毕 后 ，Git 会 被 安装 到 /usr/local/git/bin/ 目 录 下 。 重 启 终 端 程 
序 ， 这 样 /etcpaths.d/git 文 件 为 PATH 环境 变量 中 添加 的 新 路 径 注册 才能 
生效 ， 然 后 惑 可 以 在 终端 直接 运行 git 命 令 了 。 


322 安装 Xcode 


Mac OS X 基 于 Unix 内 核 开发 ， 因 此 也 可 以 很 方便 地 通过 源码 编译 
的 方式 进行 安装 ， 但 是 默认 安装 的 Mac OS X 缺 乏 相应 的 开发 工具 ， 需 
要 安装 苹果 提供 的 Xcode 软 件 包 。 在 Mac 随 机 附送 的 光盘 (Mac OS X 
Install DVD) 的 可 选 安装 文件 夹 下 就 有 Xcode 的 安装 包 (如 图 3-3 所 


示 ) ， 通 过 随机 光 强 安装 Xcode 可 以 省 去 网 络 下 载 的 麻烦 ， 要 知道 
Xcode 的 大 小 在 3GB 以 上 。 
OO (Ma 05 Xo OVD ~ 
- 


安装 Mac OS X 


量 


DVD or GD Sharing Setup 


aa 


可 选 安装 Cy 
六 了 项，83.9 M8 可 弄 


二 谣 全 


About Xcode Xcode Optional Installs 


3-3 ”在 Mac OS 义 下 安装 Xcode 


3.2.3 ”使 用 Homebrew 安 装 Git 


Mac OS X 有 好 几 个 包 管 理 器 ， 用 于 管理 一 些 开 源 软 件 在 Mac OS 
X 上 的 安装 和 升级 。 有 传统 的 MacPorts [1 、Fink 2] ， 还 有 更 为 简单 易 
用 的 Homebrew 6。 下 面 就 介绍 一 下 如 何 通过 Homebrew 包 管理 器 来 以 
源码 包 编 译 的 方式 安装 Git 。 


Homebrew 用 Ruby 语 言 开 发 ， 文 持 千 余 种 开源 软件 在 Mac OS X 中 
的 部 署 和 管理 。Homebrew 项 目 托管 在 Github 上 ， 网 址 为 : 


https://github.com/mxcl/homebrew ° 
首先 是 安装 Homebrew， 执 行 下 面 的 命令 


$ruby-e\ 
"$(curl-fsSL 
https://gist.github.com/raw/323731/install_ homebrew.rb)" 


安装 完成 后 ，Homebrew 的 主 程序 安装 在 /usr/local/bin/brew 中 ， 在 
目录 /usr/local/Library/Formula/ 下 保存 了 Homebrew 文 持 的 所 有 软件 的 安 
装 指 引文 件 。 


执行 下 面 的 命令 ， 通 过 Homebrew 安 装 Git 。 


$brew install git 


使 用 Homebrew 方 式 安装 ，Git 人 被 安装 在 /usr/local/Cellar/git/ < 
version>/ 中 ， 可 执行 程序 自动 在 /usr/local/bin 目 录 下 创建 符号 连接 ， 可 
以 直接 在 终端 程序 中 访问 。 


通过 brew list 命 令 可 以 查看 安装 的 开源 软件 包 。 


$brew list 
git 


也 可 以 查看 某 个 软件 包 安 闭 的 详细 路 径 和 安 狂 内 容 。 


$brew list git 
/usr/local/Cellar/git/1.7.4.1/bin/gitk 


[1|] http://www.macports.org/ 
[2] http://www.finkproject.org/ 
[3] http://mxcl.github.com/homebrew/ 


3.2.4 从 Git 源 码 进 行 安装 


如 果 需 要 安 逆 历史 版 本 的 Git 或 是 尚 在 开发 中 的 未 发 布 版 本 的 
Git， 束 需要 从 源码 安 厂 或 通过 克隆 Git 源 码 库 的 方式 进行 安装 。 既 然 
Homebrew 束 古 通 过 源码 编译 方式 安装 Git 的 ， 那 么 也 应 该 可 以 直接 从 
源码 进行 安装 ， 但 是 使 用 Homebrew 安 闭 Git 和 直接 通过 Git 源 码 安 狠 并 


不 完全 等 同 ， 例 如 Homebrew 安 闭 Git 文 档 是 通过 下 载 已 经 编译 好 的 Git 
文档 包 进 行 安装 ， 而 非 从 头 对 文档 进行 编译 。 


直接 通过 源码 安装 Git 软 件 及 文档 ， 遇 到 的 主要 问题 瓯 是 对 文档 的 
编译 ， 因 为 Xcode 没 有 提供 Git 文 档 编译 所 需要 的 相关 工具 。 但 是 ， 这 
些 工 具 可 以 通过 Homebrew 进 行 安装 。 安 装 工 具 软 件 的 过 程 可 能 会 遇 到 
一 些小 麻烦 ， 不 过 大 多 可 以 通过 参考 命令 输出 予以 解决 。 

$brew install asciidoc 


$brew install docbook2x 
$brew install xmlto 


当 编 译 源 码 及 文档 的 工具 部 团 完 成 后 ， 束 可 以 通过 源码 编译 Git。 


$make prefix=/usr/local all doc info 
$sudo make prefix=/usr/local install\ 
install-doc install-html install-info 


3.2.5 ”命令 补 齐 


Git 通 过 bash-completion 软 件 包 实现 命令 自动 补 齐 ， 在 Mac OS X 下 
可 以 通过 Homebrew 进 行 安装 。 


$brew search completion 
bash-completion 
$brew install bash-completion 


Add the following lines to your~/.bash profile file: 
if[-f'brew--prefix'/etc/bash_completion]; then 


.'brew--prefix'/etc/bash_completion 
fi 


根据 bash-completion 在 安 逆 过 程 中 的 提示 ， 修 改 配置 文件 
一 /.bash_profile 和 ~/.bashrc， 并 在 其 中 加 入 如 下 内 容 ， 以 便 在 终端 加 
载 时 上 自动 局 用 命令 补 齐 
if[-f 'brew--prefix'/etc/bash _ completion|;then 


.'brew--prefix'/etc/bash_completion 
fi 


将 Git 的 命令 补 齐 脚 本 拷贝 到 bash-completion 对 应 的 目录 中 。 


$cp contrib/completion/git-completion.bash\ 
'brew--prefix'/etc/bash_completion.d/ 


不 用 重启 终端 程序 ， 只 和 需要 运行 下 面 的 命令 即 可 立即 在 当前 的 
shell 中 加 载 命 令 补 齐 


.'brew--prefix'/etc/bash_ completion 


3.2.6 ”其 他 辅助 工具 的 安装 


本 书 中 还 会 用 到 一 些 常 用 的 GNU 或 其 他 开源 软件 ， 在 Mac OS X 下 
也 可 以 通过 Homebrew 进 行 安装 。 这 些 软件 包括 : 


gnupg: 数 子 签名 和 加 密 工具 ， 在 为 Git 版 本 库 建 立 签 名 里 程 碑 时 
会 用 到 3 


md5shalsum: 生成 MD5 或 SHA1 摘 要 ， 在 研究 Git 版 本 库 中 的 对 象 
时 会 用 到 。 


cvs2svn: CVS 版 本 库 迁 移 到 SVN 或 Git 的 工具 ， 在 版 本 库 迁 移 时 会 
用 到 。 


stgit: Git 的 补丁 和 提交 管理 工具 。 
quilt: 一 种 补丁 管理 工具 ， 在 介绍 StGit 时 会 用 到 。 


在 Mac OS X 下 能 够 使 用 到 的 Git 图 形 工具 除了 Git 软 件 包 自 带 的 gitk 
和 和 git gui 之 外 ， 还 有 GitX。 下 载 地 址 为 : 


GitX 的 原始 版 本 : http://gitx.frim.nl/。 


GitX 的 一 个 分 文 版 本 ， 提 供 增强 的 功能 : 
https://github.com/brotherbard/gitx/downloads ° 


Git 的 图 形 工具 一 般 需要 在 本 地 克隆 版 本 库 的 工作 区 中 执行 ,为 了 
能 与 Mac OS X 更 好 地 整合 ， 可 以 通过 插件 实现 与 Finder 的 整合 。 在 git- 
osx-installer 的 官方 网 站 : http://code.google.com/p/git-osx-installer/ 上 有 
两 个 以 OpenInGitGui- 和 OpenInGitX- 为 前 级 的 软件 包 ， 可 以 分 别 实现 与 
git gui 和 gitx 的 整合 ， 在 Finder 中 进入 工作 区 目录 ， 点 击 对 应 插件 的 
标 ， 启 动 git gui 或 gitx。 


3.2.7 ”中 文 支持 


由 于 Mac OS X 采 用 Unix 内 核 ， 在 中 文 文 持 上 与 Linux 相 近 ， 有 具体 
内 容 请 参照 第 3.1.5 节 介绍 的 在 Linux 下 安装 Git 的 相关 内 容 。 


3.3 ”在 Windows 下 安装 和 使 用 Git (Cygwin 篇 ) 


在 Windows 下 安装 和 使 用 Git 有 两 种 不 同 的 方案 : 通过 安装 msysGit 
机 或 Cygwin 中 来 使 用 Git。 在 这 两 种 不 同 的 方案 下 ，Git 的 使 用 与 Linux 
环境 下 完全 一 致 。 还 可 以 通过 msysGit 的 图 形 界面 软件 TortoiseGit 3 
(也 就 是 在 CVS 和 SVN 时 代 就 已 经 广为人知 的 Tortoise 系 列 软件 的 Git 版 
本 ) 来 使 用 Git。TortoiseGit 可 与 资源 管理 器 整合 ， 从 而 提供 Git 操 作 的 
图 形 化 界面 。 


首先 介绍 通过 Cygwin 来 使 用 Git， 并 不 是 因为 这 是 最 便捷 的 方法 。 
如 果 需 要 在 Windows 中 快速 安装 和 使 用 Git， 下 一 节 介 绍 的 msysGit 才 是 
最 便捷 的 方法 。 之 所 以 将 Cygwin 放 在 前 面 介绍 是 因为 本 书 在 介绍 Git 原 
理 和 其 他 Git 相 关 的 软件 时 用 到 了 大 量 的 开源 工具 ， 在 Cygwin 下 很 容易 
获得 这 些 开源 工 具 ， 而 msysGit 的 MSYS 14 (Minimal SYStem， 最 简 系 
统 ) 则 不 能 满足 我 们 的 需求 。 因 此 ， 我 建议 Windows 平 台 下 的 读者 在 
跟随 本 书 学 习 Git 的 过 程 中 首选 Cygwin， 当 对 Git 有 了 一 定 的 了 解 后 ， 


无 论 是 msysGiti 不 是 TortoiseGit， 您 都 会 应 对 目 如 。 


Cygwin 是 一 款 伟大 的 软件 ， 通 过 一 个 小 小 的 DLL (cygwin1.dll) 
建立 了 Linux 与 Windows 之 间 的 系统 调用 和 API 之 间 的 转换 ， 使 得 Linux 
下 的 绝 大 多 数 软件 能 同 Windows 迁 移 。Cygwin 通 过 cygwin1.dll 所 建立 


的 中 间 层 与 YMWare 5、VirtualBox lol 等 虚拟 机 软件 完全 不 同 ， 不 会 
独占 系统 资源 。 像 YMWare 等 虚拟 机 ， 只 要 启动 一 个 虚拟 机 (操作 系 
统 ) ， 即 使 不 在 其 中 执行 任何 命令 ， 同 样 也 会 占用 大 量 的 内 存 和 CPU 


时 间 等 系统 资源 。 


Cygwin 还 提供 了 一 个 强大 易 用 的 包 管 理工 具 (setup.exe) ， 使 得 
几 千 个 开源 软件 包 能 在 Cygwin 下 便捷 地 安装 和 升级 ，Git 便 是 其 中 的 一 


ll 


我 对 Cygwin 有 着 深厚 的 感情 ，Cygwin 让 我 能 在 Windows 平 台 下 用 
Linux 的 方式 更 有 效率 地 工作 ， 使 用 Linux 风 格 的 控制 台 兰 换 Windows 
墨 乎 乎 的 、 冷 冰冰 的 、 由 cmd.exe 提 供 的 命令 行 。Cygwin 帮 助 我 逐渐 摆 
脱 对 Windows 的 依赖 ， 当 我 完全 转换 到 Linux 平 台 时 ， 没 有 感到 一 丝 的 


障碍 。 


3.3.1 安装 Cygwin 


Cygwin 的 安装 非常 和 测 单 ， 先 在 其 官方 网 站 http:/www.cygwin.comy/ 
下 载 安 装 程序 一 一 一 个 只 有 几 百 KB 的 setup.exe 文 件 ， 然 后 即 可 开始 安 


装 。 
安 逆 过 程 中 会 让 用 户 选 择 安装 模式 : 通过 网 络 安装 、 下 载 后 安 效 
或 者 通过 本 地 软件 包 缓存 《安装 时 目 动 在 本 地 目 孙 下 建立 的 软件 包 组 


3-4 选择 安装 模式 


(2) 选择 安装 目录 ， 默 认为 CAcygwin， 如 图 3-5 所 示 。 这 个 目录 
将 作为 Cygwin shell 环 境 的 根 目 录 〈 根 卷 ) ，Windows 的 各 个 盘 符 将 挂 
载 在 根 卷 的 一 个 特殊 目录 之 下 。 


in Setup - Choose installation Directory 


3-5 ”选择 安装 目录 


(3) 设置 本 地 软件 包 缓存 目 了 未 ， 默 认为 setup.exe 所 处 的 目录 ， 如 
图 3-6 所 示 。 


3-6 ”选择 本 地 软件 包 缓存 目录 


(4) 设置 网 络 连接 方式 是 否 使 用 代理 等 ， 如 图 3-7 所 示 。 默 认 会 
选择 第 一 项 : “直接 网 络 连接 ”。 如 条 一 个 团队 有 很 多 人 要 使 用 
Cygwin， 架 设 一 个 能 够 提供 软件 包 缓 存 的 HTTP 代理 服务 器 会 节省 大 
量 的 网 络 带宽 和 大 量 的 时 间 。 在 Debian/Ubuntu 下 用 apt-cacher-ng [1 就 
可 以 非常 简单 地 搭建 一 个 软件 包 代理 服务 器 。 图 3-7 显 示 的 就 是 我 在 公 
司 内 网 中 安装 Cygwin 时 使 用 内 网 的 服务 器 bj.ossxp.com 作 为 HTTP 代 理 
的 情形 ， 端 口 设置 为 9999， 因 为 这 是 apt-cacher-ng 的 默认 端口 。 


二 
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3-7 是 否 使 用 代理 下 载 Cygwin 软 件 包 


(5) 选择 一 个 Cygwin 源 ， 如 图 3-8 所 示 。 如 果 在 上 一 个 步骤 中 选 
择 使 用 HTTP 代 理 服务 器 ， 就 必须 选择 HTTP 协议 的 Cygwin 源 。 


3-8 ”选择 Cygwin 源 


(6) 从 所 选 的 Cygwin 源 下 载 软 件 包 索引 文件 ， 然 后 显示 软件 包 
管理 器 界面 ， 如 图 3-9 所 示 。 


3-9 ”Cygwin 软件 包 管理 器 


Cygwin 的 软件 包 管 理 器 非常 强大 ， 而 且 易 于 使 用 (如 果 习 惯 了 其 
界面 ) 。 软 件 包 归 类 于 各 个 分 组 中 ， 点 击 分 组 前 的 加 号 就 可 以 展开 分 


组 。 在 展开 的 Admin 分 组 中 ， 如 图 3-10 所 示 (这 个 截图 不 是 首次 安装 
Cygwin 的 截图 ) ， 有 的 软件 包 〈 如 libattr1) 已 经 安装 过 了 ， 因 为 没有 
新 版 本 而 标记 为 "Keep" (保持) ， 没 有 安装 过 并 且 不 准备 安装 的 软件 
包 则 标记 为 "Skip”( 跳 过 ) 。 


| -crownsctvp -Seiect Peckenes ‘2. 了 6 因 
Seleclt Packa0es 
Seiecl peckepes to netall 


| 冲天 


3-10 ”Cygwin 软件 包 管理 颖 展开 分 组 


(7) 点 击 分 组 名 称 后 面 的 动作 名 称 (文字 "Default") ， 会 进行 软 
件 包 安 装 动作 的 切换 。 例 如 图 3-11， 将 Admin 分 组 的 安装 动作 
由 "Default”( 默 认 ) 切换 为 "Install” (安装 ) ， 会 看 到 Admin 分 组 下 的 
所 有 软件 包 都 标记 为 安装 (显示 具体 要 安装 的 软件 包 版 本 号 ; 。 也 可 
以 通过 幅 标 点 击 ， 单 独 为 软件 包 进 行 安 装 动 作 的 设 定 ， 可 以 强制 重新 
安装 、 安 效 旧 版 本 ， 或 者 不 安装 。 


= Cygwin Setup - Select Packages =Iol x) 


Select Packages 
Selecl packages to nstal C 


seuch| Be Bo Fon CED Yen| cy 


3-11 安 效 某 一 分 组 下 的 所 有 软件 


(8) 当 通过 软件 包 管理 器 对 要 安装 的 软件 包 定制 完毕 后 ， 点 击 下 
一 步 ， 开 始 下 载 软件 包 、 安 装 软件 包 和 软件 包 后 处 理 (postinstall) ， 
直至 完成 安装 。 根 据 选择 的 软件 包 的 多 少 、 网 络 情况 ， 以 及 是 否 架 设 
有 代理 服务 器 等 情况 的 不 同 ， 首 次 安装 Cygwin 的 时 间 可 能 从 几 分 钟 到 
几 个 小 时 不 等 。 


[1| http://code.google.com/p/msysgit/ 
[2] http://www.cygwin.com/ 

[3] http://code.google.com/p/tortoisegit/ 
[4] http://www.mingw.org/wiki/msys 
[5] http:/www.vmware.com/ 

[6] http://www.virtualbox.org/ 


[7] http://www.unix-ag.uni-kl.de/~bloch/acng/ 


3.3.2 ”安装 Git 


默认 安装 的 Cygwin 没 有 安装 Git 软 件 包 。 如 果 在 首次 安 效 过 程 中 起 
记 通 过 包 管 理 侣 选择 安 狠 Git 或 其 他 相关 软件 包 ， 可 以 在 安 效 后 再 次 
行 Cygwin 的 安装 程序 setup.exe。 当 再 次 进入 Cygwin 包 管理 硕 界 面 时 ， 
在 搜索 框 中 输入 git， 如 图 3-12 所 示 。 


a 


| -crownseuup Select Packages A 
Select Packages 
Select paockages to nstal 有 
Seach [od Gea| © keep 人 Bev 有 tun CT Exwp Vew | Caegoy 


日 Devel © Defaukh 
‘ 2639k oR Fast Verson Co 

kp MN wo 1 蒜 缚 'compleiorr Fst 

7 onout Fast Version 


47Bk stgk Quk funciona 
时 


因 Pshon #7 Deivsk 
» 


[7 了” Hide obsolete packages 
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3-12 Cygwin 软件 包 管 理 器 中 搜索 git 


从 图 3-12 中 可 以 看 出 在 Cygwin 中 包含 了 很 多 与 Git 相 关 的 软件 包 ， 
把 这 些 Git 相 关 的 软件 包 全 部 都 安 六 上 吧 ， 如 图 3-13 所 示 。 


~ Cygwin Setup ~ Select Packages IDIxXl 


Select Packages 
Selec! pack aget to nstall EE 


Search[ot 六 keep C Bev F Om CF Ew View | caeoow 
Calegoy | Cment | 


日 Devel 心 Instal 
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他 17331 oR-completion: Fost 
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他 015-2 stgi Qu funclona 


3-13” ”Cygwin 软件 包 管 理 絮 中 安装 git 
需要 安装 的 其 他 软件 包 还 有 : 


git-completion: 提供 Git 命 令 的 目 动 补 齐 功 能 。 安 装 该 软件 包 时 会 
目 动 安装 其 所 依赖 的 bash-completion 软 件 包 。 


openssh: SSH 客 户 端 ， 为 访问 SSH 协 议 的 版 本 库 提 供 文 持 。 


vim: Git 默 认 的 编辑 器 。 


3.3.3 Cygwin 的 配置 和 使 用 


运行 Cygwin 后 会 进入 shell 环 境 并 见 到 熟悉 的 Linux 提 示 和 从， 如 图 3- 
14 所 示 。 


Copying skeleton files 
These files are for the User to personalise their cyQuin experience 


They will never be overwritten nor autonatically updated 


/ .bashrc > /home/ a 


/home/ ]Iangxlin 


3-14 ”运行 Cygwin 


可 以 通过 执行 cygcheck 命 令 来 查看 Cygwin 中 安装 的 软件 包 的 版 
本 。 例 如 ， 查 看 Cygwin 软 件 包 本 身 的 版 本 : 


$cygcheck-c cygwin 

Cygwin Package Information 
Package Version Status 
cygwin 1.7.7-1 OK 


1. 如 何 访问 Windows 的 盘 符 


刚刚 接触 Cygwin 的 用 户 遇 到 的 头 一 个 问题 束 是 ，Cygwin 如 何 访问 
Windows 的 各 个 磁盘 目录 ， 以 及 在 Windows 平 台 下 如 何 访问 Cygwin 中 
的 目录 。 


执行 mount 命令 后 可 以 看 到 Windows 下 的 盘 符 被 映 映 到 /cygdrive 特 
由 内 孙 下 


$mount 

:/cygwin/bin on/usr/bin type ntfs(binaryy auto ) 

:/cygwin/1lib on/usr/1lib type ntfs(binary,auto) 

:/cygwin on/type ntfs(binary,auto) 

:on/cygdrive/c type ntfs(binary,posix=0,user,noumount,auto) 
:on/cygdrive/d type ntfs(binary,posix=0,user,noumount,auto) 


DONONOO 


也 残 是 说 ， 在 Cygwin 中 以 路 径 /cygdrive/oWindows 来 访问 Windows 
下 的 C:\Windows 目录 。 实 际 上 ，Cygwin 提 供 cygpath 命 令 来 实现 
Windows 平 台 和 Cygwin 之 间 目 录 名 称 的 变换 ， 如 下 所 示 : 

$cygpath-u C:\\Windows 
/cygdrive/c/Windows 
$cygpath-w~/ 
C:\cygwin\home\jiangxin\ 
从 上 面 的 示例 也 可 以 看 出 ，Cygwin 下 的 用 户主 目录 
( 即 /home/jiangxin/) 相当 于 Windows 下 的 C:cygwin\homeAjiangxinN 目 
最 


2. 用 户主 目 孙 不 一 致 的 问题 


如 果 某 些 其 他 软件 (如 msysGit) 为 Windows 设 置 了 HOME 环境 变 
量 ， 会 影响 到 Cygwin 中 用 户主 目录 的 设置 ， 甚 至 会 造成 在 Cygwin 中 不 
同 的 命令 有 不 同 的 用 户主 目录 的 情况 。 例 如 : Cygwin 下 Git 的 用 户主 目 
录 被 设置 为 /cygdrive/oDocuments and Settings/jiangxin， 而 SSH 客 户 端 
软件 的 主 目录 被 设置 为 /home/jiangxin， 这 会 给 用 户 造成 困惑 。 


之 所 以 出 现 这 种 情况 ， 是 因为 Cygwin 确 定 用 户主 目录 有 几 个 不 同 
的 依据 ， 权 按照 顺序 确定 主 目 永 : 首先 查看 系统 的 HOME 环境 变量 ， 
其 次 查看 /etcpasswd 中 为 用 户 设置 的 主 目 示 。 有 的 软件 遵照 这 个 原 
则 ， 而 有 些 Cygwin 应 用 如 SSH， 却 没有 使 用 HOME 环境 变量 而 是 直接 
使 用 /etc/passwd 中 的 设置 。 要 想 避 免 在 同一 个 Cygwin 环 境 下 有 两 个 不 
同 的 用 户主 目录 设置 ， 可 以 采用 下 面 两 种 方法 。 


方法 1: 修改 Cygwin 局 动 的 批 处 理 文件 (如 : 
Ci\cygwin\Cygwin.bat) ， 在 批 处 理 的 开头 添加 如 下 的 一 行 代码 ， 就 可 
以 防止 其 他 软件 在 Windows 引 入 的 HOME 环 境 变量 被 带 入 到 Cygwin 
中 o 


Set HOME= 


方法 2: 如 果 硕 望 使 用 HOME 环境 变量 指 同 的 主 目 示 ， 则 可 通过 手 
工 编辑 /etc/passwd 文 件 ， 将 其 中 的 用 户主 目录 修改 成 HOME 环 境 变 量 
所 指向 的 目录 中 。 


3. 命 令 行 补 齐 忽略 文件 名 大 小 写 


Windows 的 文件 系统 忽略 文件 名 的 大 小 写 ， 在 Cygwin 下 最 好 对 命 
令 行 补 齐 进行 相关 设置 ， 以 忽略 大 小 写 ， 这 样 使 用 起 来 更 方便 。 


编辑 文件 ~/inputrc， 在 其 中 添加 设置 "set completion-ignore-case 
on"， 或 者 取消 已 有 的 相关 设置 前 面 的 井 (#) 号 注释 符 。 修 改 完毕 
后 ， 再 重新 进入 Cygwin， 这 样 束 可 以 实现 命令 行 补 齐 对 文件 名 大 小 写 
忽略 。 


IIE 


4. 忽 略 文件 权限 的 可 执行 位 


Linux、UNIX、Mac OS X 通 过 文件 权限 中 的 可 执行 位 判断 文件 是 
否 可 执行 ， 而 Windows 是 通过 文件 扩展 名 进行 判断 的 。Git 提 供 对 类 
UNIX 系 统 文件 权限 的 支持 ， 在 版 本 库 中 建立 对 可 执行 文件 的 追踪 。 对 
于 Windows 平 台 ，Git 的 这 个 特性 用 处 不 大 ， 其 至 有 害 。 因 为 ， 虽然 
Cygwin 可 以 模拟 Linux 下 的 文件 授权 并 对 文件 的 可 执行 位 提供 支持 ， 
但 为 支持 文件 权限 而 调用 Cygwin 的 stat() 函 数 和 lstat() 画 数 会 比 调用 
Windows 自 身 的 Win32 API 要 慢 一 半 上 ， 而 且 非 跨 平台 的 项 目 也 没有 
必要 对 文件 权限 位 进行 跟踪 ， 甚 至 Windows 下 的 其 他 工具 及 操作 可 能 
会 破坏 文件 的 可 执行 位 ， 从 而 导致 Cygwin 下 的 Git 认 为 文件 的 权限 更 改 
需要 重新 提交 。 通 过 下 面 的 配置 可 以 禁止 Git 对 文件 权限 的 跟踪 : 


$git config--system core.fileMode false 


在 此 模式 下 ， 当 已 添加 到 版 本 库 中 的 文件 的 权限 的 可 执行 位 改变 
时 ， 该 文件 不 会 显示 有 改动 。 版 本 库 中 新 增 的 文件 ， 无 论文 件 本 身 是 
否 设置 为 可 执行 ， 都 以 100644 的 权限 (忽略 可 执行 位 ) 进行 添加 。 


关于 Cygwin 的 更 多 内 容 ， 请 参见 网 址 


http://www.cygwin.com/cygwin-ug-net/ 中 的 信息 。 


[1| http://www.cygwin.com/cygwin-ug-net/ntsec.html 
[2] git-config (1) 用 户 手 册 中 关于 core.ignoreCygwinFSTricks 的 介绍 。 


3.3.4 Cygwin 下 Git 的 中 文 支持 


Cygwin 的 当前 版 本 是 1.7.x， 对 中 文 的 支持 非常 好 。 无 需 任何 配置 
就 可 以 在 Cygwin 的 窗口 内 输入 中 文 ， 执行]s 命 令 就 可 以 显示 中 文 的 文 
件 名 。 这 与 六 七 年 前 的 Cygwin 1.5.x 完 全 不 一 样 了 ， 老 版 本 的 Cygwin 
还 需要 进行 一 些 配置 才能 在 控制 台 输 入 中 文 和 显示 中 文 ， 但 是 最 新 版 
本 的 Cygwin 已 经 完全 不 需要 了 。 后 面 要 介绍 的 msysGit 的 shell 环 境 仍然 
需要 进行 相关 的 配置 〈 同 老 版 本 Cygwin) 才能 够 正常 显示 和 输入 中 
文 。 


Cygwin 默 认 使 用 UTF-8 字 符 集 ， 并 能 巧妙 地 与 Windows 系 统 的 字 
符 集 进行 转换 。 在 Cygwin 下 可 执行 locale 命 令 查 看 Cygwin 下 正在 使 用 
字 


$locale 

LANG=C .UTF-8 
LC_CTYPE="C .UTF-8" 
LC_NUMERIC="C.UTF-8" 
LC_TIME="C.UTF-8" 
LC_COLLATE="C.UTF-8" 
LC_MONETARY="C.UTF-8" 
LC_MESSAGES="C.UTF-8" 
LC_ALL= 


正 因为 如 此 ，Cygwin 下 的 Git 对 中 文 的 支持 也 非常 出 色 。 虽 然 中 文 
的 Windows 本 号 使 用 GBK 字 符 集 ， 但 是 在 Cygwin 下 ，Git 就 如 同 工 作 在 


采用 UTF-8 字 符 集 的 Linux 下 ， 对 中 文 的 文 持 非 党 的 好 : 


在 提交 时 ， 可 以 在 提交 说 明 中 输入 中 文 。 


显示 提交 历史 时 ， 能 够 正 闻 显示 提交 说 明 中 的 中 文字 符 。 


可 以 添加 文件 名 称 为 中 文 的 文件 ， 并 可 以 在 使 用 UTF-8 字 符 集 的 
Linux 环 境 中 克隆 和 检 出 。 


可 以 创建 市 有 中 文字 符 的 里 程 碑 名 称 。 


但 是 和 Linux 平 台 一 样 ， 在 默认 设置 下 ， 文 件 名 称 中 包含 中 文 的 文 
件 ， 在 工作 区 状态 输出 、 碍 看 历史 更 改 概要 ， 以 及 在 补丁 文件 中 ， 文 
件 名 中 的 中 文 不 能 正确 地 显示 ， 而 是 用 奉 干 八进制 字符 编码 来 显示 ， 
如 下 : 


$git status-s 

?7 "\350\257\264\346\230\216.txt" 
$printf "\350\257\264\346\230\216.txt" 
说 明 ,txt 


配置 变量 core.quotepath 设 置 为 false 就 可 以 解雇 中 文 文 件 名 在 这 些 
Git 命 令 输出 中 的 显示 问题 。 
$git config--global core.quotepath false 


$git status-s 
?3 说 明 .txt 


3.3.5 Cygwin 下 Git 访 问 SSH 服 务 


在 本 书 第 5 篇 第 29 草 中 介绍 的 以 公 钥 认证 的 方式 访问 Git 服 务 ， 十 
实现 Git 写 操作 的 最 重要 的 服务 。 以 公 钥 认证 方式 访问 SSH 协 议 的 Git 服 
务 右 时 无 须 输 入 口令 ， 而 且 更 安全 。 使 用 公 钥 认证 就 涉及 如 何 创建 公 
钥 / 私 钥 对 ， 以 及 在 SSH 连 接 时 应 该 选择 哪 一 个 私 钥 的 问题 “如果 建立 
有 多 个 私 钥 ) 。 


Cygwin 下 的 openssh 软 件 包 提供 的 ssh 命 令 和 Linux 下 的 ssh 命 令 没 有 
什么 区 别 ， 也 提供 了 ssh-keygen 命 令 来 管理 SSH 公 钼 / 私 钥 对 。 但 是 ， 
Cygwin 当 前 的 openssh 〈 版 本 号 : 5.7p1-1) 有 一 个 Bug， 使 用 Git 克 隆 采 
用 SSH 协 议 的 版 本 库 时 侦 尔 会 中 断 ， 从 而 无 法 完成 版 本 库 的 克隆 。 示 
例如 下 : 

$git clone git@bj.ossxp.com:ossxp/gitbook.git 

Cloning into gitbook... 

remote:Counting objects:3486, done. 

remote:Compressing objects:100%(1759/1759), done. 
fatal:The remote end hung up unexpectedly MiB|3.03 MiB/s 


fatal:early EOFs:75%(2615/3486),13.97 MiB|3.03 MiB/s 
fatal:index-pack failed 


如 果 您 也 遇 到 同样 的 问题 ， 建 议 使 用 PuTTY 提 供 的 plink.exe 作 为 
SSH 客 户 端 ， 蔡 代 Cygwin 自 带 的 ssh 命 令 。 


1. 安 装 PuTTY 


PuTTY 是 windows 下 的 一 个 开源 软件 ， 提 供 SSH 客 户 端 服务 ， 还 
包括 公 钥 管理 的 相关 工具 。 访 问 PuTTY 的 主页 
(http:Wwww.chiark.greenend.org.uk/~sgtatham/putty) ， 下 载 并 安装 
PuTTY。 安 净 完 毕 会 发 现 PuTTY 软 件 包 包含 了 多 个 可 执行 程序 ， 下 面 
几 个 命令 用 于 与 Git 的 整合 。 


Plink: 即 plink.exe， 是 命令 行 的 SSH 客 户 端 ， 用 于 替代 ssh 命 令 。 


默认 安装 于 C:\Program Files\PuTTY\plink.exe 路 径 中 。 


PuTTYgen: 用 于 管理 PuTTY 格 式 的 私 铀 ， 也 可 以 用 于 将 openssh 
格式 的 私 钥 转换 为 PuTTY 格 式 的 私 钥 。 


Pageant: SSH 认 证 代理 ， 运 行 于 后 台 ， 负 责 为 SSH 连 接 提供 私 铀 
访问 服务 。 

2.PuTTY 格 式 的 私 铀 

PuTTY 使 用 专 有 格式 的 私 钥 文 件 (扩展 名 为 .ppk) ， 而 不 能 直接 
使 用 openssh 格 式 的 私 钥 。 也 就 是 用 openssh 的 ssh-keygen 命 令 创建 的 私 


钥 不 能 直接 被 PuTTY 拿 过 来 使 用 ， 必 需 经 过 转换 ， 程 序 PuTTYgen 可 以 
实现 私 钥 格 式 的 转换 。 


运行 PuTTYgen 程 序 ， 如 图 3-15 所 示 。 


E PuTJTY Key Generator 
Eile Key Conversions Hep 
Key 
No key. 


Aclhons 

Geneate a public/private key par 
Load an enisting piivate key le 
Save the generaled key 


Parametess 


Type of key to genetale: 
SSH-1 {RSA] 全 SSH28RSA © S5H.20D5SA 
Nember of bits In a gererated key |1024 


3-15 ”运行 PuTTYgen 程 序 


PuTTYgen 既 可 以 重新 创建 私 钥 文 件 ， 又 可 以 通过 点 击 加 载 按钮 
(oad) 读 取 openssh 格 式 的 私 钥 文件 ， 从 而 可 以 将 其 转换 为 PuTTY 格 
式 的 私 铀 。 点 击 加 载 按钮 ， 会 弹出 文件 选择 对 话 框 ， 选 择 openssh 格 式 
的 私 钥 文 件 (如 文件 id_rsa) ， 如 果 转 换 成 功 ， 会 显示 如 图 3-16 的 界 
面 o 


¥ PuTTY Key Generator 

Ble Key Conversions Hep 
Key 
Eublic key for pasting into OpenSSH authorized_keys fle: 
ssh'rsa 
Pn 
AImQchfViCs4T 基 EyvzWa79sTB8a 的 Ci Oe 
A im heed ls PUTTYEen Notice 
VuPsaStpuPLU YDsulRBR ?7zUorrys 


i i Successfully imported foreign key 
Key fngesprint sshssa 2048 4 | ‘ SH SSH2 Private key), 
To use this key with PUTTY, ¥ou need to 
Use the "Save privake key” command to 
save Rin PuTTYS own format, 


es 


Load an existing peivale key fe 


Save the generated key Save public key 


Parametess 


Type of key to generale: 
S55H-1 {RSA] 人 5S5H-2RSA O 55H-:2 DSA 


Number of bits in a gerrerated key ge4 


3-16 PuTTYgen 完 成 私 钥 加 载 


然后 点 击 "Save private key" (保存 私 钥 ) ， 就 可 以 将 私 钥 保 存 为 
PuTTY 的 .ppk 格 式 ， 例 如 将 私 钥 保 存 到 文件 ~/.ssh/jiangxin-cygwin.ppk 
中 o 


3.Git 使 用 Pageant 进 行 公 钥 认证 


Git 在 使 用 命令 行 工具 Plink (plink.exe) 作为 SSH 客 户 端 访问 SSH 
协议 的 版 本 库 服 务 器 时 ， 如 何 选 择 公 钥 呢 ? 使 用 Pageant 是 一 个 非常 好 
的 选择 。Pageant 是 PuTTY 软 件 包 中 的 代理 软件 ， 为 各 个 PuTTY 应 用 提 


供 私 钥 请 求 ， 当 Plink 连 接 SSH 服 务 硕 需要 请 求 公 钥 认 证 时 ，Pageant 焉 
会 给 Plink 提 供 相应 的 私 钥 。 


运行 Pageant， 局 动 后 会 在 托盘 区 显示 一 个 图 标 ， 在 后 侣 运行 。 使 
用 鼠标 右键 单 击 Pageant 的 图 标 ， 束 会 弹出 相关 的 沫 单 ， 如 图 3-17 所 
示 。 


New 5ession 
Saved 5e55lon5 上 


Yiew Keys 
Add Key 


Help 
About 


Exit 


图 3-17 Pageant 的 弹出 菜单 
点 击 弹出 菜单 中 的 "Add Key”( 添 加 私 钥 ) 按钮 ， 会 弹出 文件 选择 


框 ， 选 择 扩展 名 为 .ppk 的 PuTTY 格 式 的 公 钥 ， 即 完成 了 Pageant 的 私 钥 
准备 工作 。 


接 下 来 ， 还 需要 对 Git 进 行 设置 ， 设 置 Git 使 用 plink.exe 作 为 SSH 客 
户 端 ， 而 不 是 默认 的 ssh 命 令 。 通 过 设置 GIT_SSH 环 境 变 量 即 可 实现 : 


$export GIT_SSH=/cygdrive/c/Program\Files/PuTTY/plink.exe 


上 面 在 设置 GIT_SSH 环 境 变 量 的 过 程 中 使 用 了 Cygwin 格 式 的 路 
径 ， 而 非 Windows 格 式 的 ， 因 为 Git 是 在 Cygwin 的 环境 中 调用 plink.exe 
命令 的 ， 所 以 要 使 用 Cygwin 能 够 理解 的 路 径 。 


这 样 束 可 以 用 Git 访 问 SSH 协 议 的 Git 服 务 嚣 了。 运行 在 后 台 的 
Pageant 会 在 需要 的 时 候 为 plink.exe 提 供 私 钥 访问 服务 ， 但 在 首次 连接 
一 个 使 用 SSH 协 议 的 Git 服 务 器 的 时 候 ， 很 可 能 会 因为 远程 SSH 服 务 器 
的 公 钥 没有 经 过 确认 而 导致 git 命 令 执行 失败 。 例 如 : 


$git clone git@bj.ossxp.com:ossxp/gitbook.git 

Cloning into gitbook... 

The server's host key is not cached in the registry.You 

have no guarantee that the server is the computer you 

think it is. 

The server's rsa2 key fingerprint is: 

ssh-rsa 2048 49:eb:04:30:70:ab:b3:28:;42:03:19:fe:82:f8:1a:00 
Connection abandoned. 

fatal:The remote end hung up unexpectedly 


这 是 因为 在 首次 连接 SSH 服 务 器 时 要 对 其 公 钥 进行 确认 (以 防止 

被 钓鱼 ) ， 而 运行 于 Git 下 的 plink.exe 没 有 机 会 从 用 户 那里 获取 输入 ， 

以 建立 对 该 SSH 服 务 器 公 钥 的 信任 ， 因 此 Git 访 问 失 败 。 解 决 办 法 非常 

简单， 直接 运行 plink.exe 连 接 一 次 远程 SSH 服 务 右 ， 并 对 公 钥 确认 进行 

应 答 即 可 。 操 作 如 下 : 
$/cygdrive/c/Program\Files/PuTTY/plink.exe git@bj.ossxp.com 
The server's host key is not cached in the registry.You 
have no guarantee that the server is the computer you 


think it is. 
The server's rsa2 key fingerprint is: 


ssh-rsa 2048 49:eb:04:30:70:ab:b3:28:;42:03:19:fe:82:f8:1a:00 
If you trust this host,enter"y"to add the key to 

PuTTY's cache and carry on connecting. 

If you want to carry on connecting just once,without 

adding the key to the cache,enter "Nn". 

If you do not trust this host,press Return to abandon the 
connection. 

Store key in cache?(y/n) 


输入 "y"， 将 公 钥 保存 在 信任 链 中 ， 以 后 再 和 该 主机 连接 时 就 不 会 
弹出 该 确认 应 答 了 。 当 然 ，Git 命 令 也 就 可 以 成 功 执行 了 。 


4. 使 用 自 定义 SSH 肢 本 取代 Pageant 


使 用 Pageant 时 还 要 在 它 每 次 局 动 时 手动 选择 私 钥 文 件 ， 这 比较 麻 
烦 。 实 际 上 ， 可 以 创建 一 个 脚本 对 plink.exe 进 行 封装 ， 在 封装 的 脚本 
中 使 用 -i 参数 指定 私 钥 文 件 。 


例如 ， 创 建 脚本 ~/bin/ssh-jiangxin， 文 件 内 容 如 下 : 


#!/bin/sh 
/cygdrive/c/Program\Files/PuTTY/plink.exe-T-i\ 
c:/cygwin/home/jiangxin/.ssh/jiangxin-cygwin.ppk$* 


设置 该 脚本 为 可 执行 脚本 。 


$chmod a+x~/bin/ssh-jiangxin 


使 用 下 面 的 命令 通过 该 脚本 与 远程 SSH 服 务 器 连接 : 


$~/bin/ssh-jiangxin git@bj.ossxp.com 


Using username "git"， 

hello jiangxin,the gitolite version here is v1.5.5-9-g4c1i1ibd8 
the gitolite config gives you the following access: 
R gistore-bj.ossxp.com/.*$ 

gistore-ossxp.com/.*$ 

R W ossxp/.*$ 

W test/repol1 

W test/repo2 

W test/repo3 

Q@RQW test/repo4 

Q@CQ@R W users/jiangxin/.+$ 


力 力 器 刀 


刀 


设置 GIT_SSH 变 量 ， 使 之 指向 新 建立 的 脚本 ， 然 后 就 可 以 脱离 
Pageant 来 连接 SSH 协 议 的 Git 库 了 。 


$export GIT_SSH=~/bin/ssh-jiangxin 


3.4 Windows 下 安装 和 使 用 Git (msysGit 篇 ) 


运行 在 Cygwin 下 的 Git 不 直接 使 用 Windows 的 系统 调用 ， 而 是 通过 
二 传 手 cygwin1.dl 来 进行 的 。 虽 然 Cygwin 中 的 Git 能 够 在 Windows 下 的 
cmd.exe 命 令 窗 口中 运行 良好 ， 但 Cygwin 下 的 Git 并 不 能 被 看 作 是 
Windows 下 的 原生 程序 。 相 比 Cygwin 下 的 Git,msysGit 才 是 原生 的 
Windows 程 序 ，msysGit 下 运行 的 Git 是 直接 通过 Windows 的 系统 调用 来 


运行 的 。 


msysGit 名 字 前 面 的 四 个 字母 来 源 于 MSYS [11 项目。MSYS 项 目 源 
自 于 MinGW I” (Minimalist GNU for Windows， 最 简 GNU 工 具 集 ) ， 
通过 增加 一 个 bash 提 供 的 shell 环 境 及 其 他 相关 的 工具 软件 组 成 了 一 个 
最 简 系 统 (Minimal SYStem) ， 简 称 MSYS。 利 用 MinGW 提 供 的 工具 
和 Git 针 对 MinGW 的 一 个 分 支 版 本 ， 在 Windows 平 台 为 Git 编 译 出 一 个 
原生 应 用 ， 结 合 MSYS 就 组 成 了 msysGit 。 


3.4.1 安装 msysGit 
安装 msysGit 非 常 答 单 ， 访 问 msysGit 的 项 目 主 页 


(http://code.google.com/p/msysgit/) ， 下 载 msysGit。 最 简单 的 方式 是 
下 载 名 为 Git- <VERSION > -preview <DATE> .exe 的 软件 包 ， 如 Git- 


1.7.3.1-preview20101002.exe。 如 果 您 有 时 间 和 耐心 ， 想 观察 Git 是 如 何 
在 windows 上 被 编译 为 原生 应 用 的 ， 也 可 以 下 载 市 msysGit-fullinstall- 
前 级 的 软件 包 。 


点 击 安装 程序 (如 Git-1.7.3.1-preview20101002.exe) 开始 安装 ， 
如 图 3-18 所 示 。 


Git Setup El xi 
Welcome to the Git Setup Wizard 


This will install Git version 1,7,3,1-preview20101002 on your 
COMOAREr, 


tis recommended that you close al other applcations before 
continung, 


Click Next to copkimbe or Cancel to exit Setup， 


3-18 ”启动 msysGit 安 装 


默认 安装 到 C:\Program Files\Git 目 录 中 ， 如 图 3-19 所 示 。 


a 


Select Destination Location mn 


Where should Gt be instaled? 5 


Ga Setup will install GX into the folowing Foyder , 


To continue, oick Next, 开 you would ke to select a different Folder, ck Browse, 


Mt east 56.9 MB of free disk space is requred, 
Pup /ey ood 


3-19 ”选择 msysGit 的 安装 目录 


在 安装 过 程 中 会 询问 是 否 修改 环境 变量 ， 如 图 3-20 所 示 。 默 认 选 
择 "Use Git Bash Only"， ee (类 似 
Cygwin) 中 使 用 Git， 不 修改 环境 变量 。 注 意 ， 如 果 选 择 最 后 一 项 ， 会 
将 msysGit 所 有 的 可 执行 程序 全 部 加 入 Windows 的 PATH 路 径 中 ， 有 的 命 
令 会 覆盖 Windows 相 同文 件 名 的 程序 (如 find.exe 和 sort.exe) 。 而 且 ， 
如 果 选 择 最 后 一 项 ， 还 会 为 Windows 添 加 HOME 环 境 变 量 ， 如 果 安 装 
有 ee | 入 的 HOME 环 境 变 量 的 影响 ( 参 
见 前 面 3.3.3 节 的 相关 讨论 ) 。 


起 Setup 
Adjusting your PATH environment 
How would You like to use GR from the command line? 


图 3-20 ”是否 修改 系统 的 环境 变量 


还 会 询问 换行 符 的 转换 方式 ， 使 用 默认 设置 就 可 以 了 ， 如 图 3-21 
所 示 。 关 于 换行 符 转 换 的 内 容 ， 请 参见 本 书 第 8 篇 的 相关 章节 。 


| Configuring the line ending conversions 
| How should Git treat line endings in text files? 


3-21 ”换行 从 转换 方式 
根据 提示 完成 msysGit 的 安装 。 


[1| http://www.mingw.org/wiki/msys 


[2| http:/www.mingw.org/ 


3.4.2 msysGit 的 配置 和 使 用 


完成 msysGit 的 安装 后 ， 点 击 Git Bash 图 标 ， 局 动 msysGit， 如 图 3- 
22。 会 发 现 Git Bash 的 界面 和 和 Cygwin 的 非常 相像 。 


Run “git heip git play the help imdex 
heip + 


to dis 
Run “Qit help 《connand>” to Sisplioy p for specifice comnands 


3-22 ”启动 Git Bash 
1. 如 何 访问 Windows 的 盘 符 


在 msysGit 下 访问 Windows 的 各 个 盘 从 要 比 Cygwin 人 简单 ， 直 接 通 
过 %c" 即 可 访问 Windows 的 C 盘 ， 用 "%d" 即 可 访问 Windows 的 D 盘 。 


$1s-ld/c/Windows 
drwxr-xr-x 233 jiangxin Administ 0 Jan 31 00:44/c/Windows 


msysGit 的 根 目 隶 实 际 上 就 是 msysGit 的 安装 目录 ， 如 "C:\Program 
Files\Git" ° 


2. 命 令 行 补 齐 和 忽略 文件 大 小 写 


msysGit 默 认 已 经 安装 并 局 用 了 Git 的 命令 行 补 齐 功 能 ， 是 通过 在 
文件 /etc/profile 中 加 载 相 应 的 脚本 实现 的 。 


./etc/git-completion.bash 


msysGit 还 文 持 在 命令 行 补 齐 时 忽略 文件 名 的 大 小 写 ， 这 是 因为 
msysGit 已 经 在 配置 文件 /etc/inputrc 中 包含 了 下 列 的 设置 : 


set completion-ignore-case on 


3.4.3 ”msysGit 中 shell 环 境 的 中 文 文 持 


在 介绍 Cygwin 时 曾经 提 到 过 ，msysGit 的 shell 环 境 的 中 文 支持 情况 
与 老 版 本 的 Cygwin 1 类似， 需要 配置 才能 够 录入 中 文 和 显示 中 文 。 


1. 中 文 录入 问题 


默认 安装 的 msysGit 的 shell 环 境 中 无 法 输入 中 文 。 为 了 能 在 shell 界 
面 中 输入 中 文 ， 需要 修改 配置 文件 /etc/inputrc， 增 加 或 修改 相关 的 配 
置 如 下 : 


#disable/enable 8bit input 
set meta-flag on 

set input-meta on 

set output-meta on 

set convert-meta off 


关闭 Git Bash 再 重启 ， 就 可 以 在 msysGit 的 shell 环 境 中 输入 中 文 
a 


$echo 您 好 
您 好 


2. 分 页 右 中 文 输出 问题 


对 /etc/inputrc 进 行 正确 的 配置 之 后 就 能 够 在 shell 环 境 下 输入 中 文 
了 ， 但 是 执行 下 面 的 命令 时 会 显示 乱码 。 这 显然 是 less 分 页 器 命令 导致 


的 问题 。 


$echo 您 好 | less 
<C4> <FA> <BA> <C3> 


通过 管道 符 调用 分 页 器 命令 less 后 ， 原 本 的 中 文 输出 变 成 了 乱码 显 
示 。 因 为 Git 使 用 了 大 量 的 less 命 令 作为 分 页 器 ， 这 导致 Git 的 很 多 命令 
的 输出 都 出 现 了 中 文 乱 码 的 问题 。 之 所 以 less 命 令 会 导致 出 现 乱 码 ， 是 
因为 该 命令 没有 把 中 文 当 作 正 常 的 字符 ， 可 以 通过 设置 
LESSCHARSET 环 境 变 量 将 UTF-8 编 码 字 符 视 为 正常 的 字符 ， 于 是 中 
文 束 能 正常 显示 了 。 下 面 的 操作 可 以 使 less 分 页 右 中 的 中 文正 常 显 示 : 


$export LESSCHARSET=utf-8 
$echo 您 好 |less 
您 好 


编辑 配置 文件 /etc/profile， 将 对 环境 变量 LESSCHARSET 的 设置 加 
入 其 中 ， 以 便于 msysGit 的 shell 环 境 启 动 时 就 加 载 。 


declare-x LESSCHARSET=utf-8 


3.1s 命 令 显示 中 文 文件 名 


最 常用 的 用 于 显示 目录 和 文件 名 列表 的 命令 ls 在 显示 中 文 文件 名 
的 时 候 也 有 问题 。 下 面 的 命令 创建 了 一 个 中 文 名 称 的 文件 ， 文 件 内 容 
中 的 中 文 在 显示 时 没有 问题 ， 但 是 文件 名 却 显 示 为 一 串 问 号 。 


$echo 您 好 > 您 好 .txt 
$cat\*.txt 

您 好 

$ls\*.txt 

2222 .txt 


实际 上 ， 只 要 在 ls 命令 后 添加 参数 --show-control-chars 即 可 正确 显 
示 中 文 : 


$1lLSs- -Show-control-chars* ,txXt 
您 好 .txt 
为 方便 起 见 ， 可 以 为 ls 命令 设置 一 个 别名 ， 这 样 束 不 必 在 输入 ls 命 
令 时 输入 长 长 的 参数 了 。 
$alias ls="]s--show-control-chars" 


$ls\*.txt 
您 好 .txt 


将 上 面 的 alias 命 令 添加 到 配置 文件 /etc/profile 中 ， 可 实现 在 每 次 运 
行 Git Bash 时 自动 加 载 。 


党 
站 
由 
吕 
让 


[1] MSYS 是 源 目 于 Cygwinl3 的 轻 量 


http:/www.mingw.org/) 。 


3.4.4 msysGit 中 Git 时 中 文 文 择 


非常 遗憾 的 是 ，msysGit 中 的 Git 对 中 文 支持 不 如 Cygwin 中 的 
Git,msysGit 中 的 Git 对 中 文 的 支持 情况 与 前 面 讨论 过 的 使 用 了 GBK 字 符 
集 的 Linux 环 境 下 的 Git 相 当 。 


(1) 使 用 未 经 配置 的 msysGit 提 交 ， 如 果 提 交 说 明 中 包含 中 文 ， 
从 Linux 平 台 或 其 他 UTF-8 字 符 集 平台 上 查看 提交 说 明 时 会 显示 为 乱 
人 码 。 


(2) 同样 ， 从 Linux 平 台 或 其 他 使 用 UTF-8 字 符 集 平台 进行 的 提 
交 ， 若 提交 说 明 包 含 中文 ， 在 未 经 配置 的 msysGit 中 也 会 显示 为 想 码 。 


(3) 如 果 使 用 msysGit 向 版 本 库 中 添加 带 有 中 文 文件 名 的 文件 ， 
在 Linux (或 其 他 UTF-8) 平台 检 出 文件 名 时 会 显示 为 乱码 ， 反 之 亦 


(4) 不 能 创建 带 有 中 文字 符 的 引用 《里 程 碑 和 分 文 等 ) 。 


如 果 和 希望 版 本 库 中 出 现 使 用 中 文 文件 名 的 文件 ， 最 好 不 要 使 用 
msysGit， 而 应 该 使 用 Cygwin 下 的 Git。 如 果 只 是 想 在 提交 说 明 中 使 用 
中 文 ， 对 msysGit 进 行 一 定 的 设置 后 还 是 可 以 实现 的 。 


为 了 解决 提交 说 明显 示 为 乱码 的 问题 ，msysGit 要 为 Git 设 置 参数 
il8n.logOutputEncoding， 将 提交 说 明 的 输出 编码 设置 为 gbk: 


$git config--system i1i8n.logOutputEncoding gbk 


Git 在 提交 时 并 不 会 对 提交 说 明 进 行 从 GBK 字 符 集 到 UTF-8 字 符 集 
的 转换 ， 但 是 可 以 在 提交 说 明 中 标注 所 使 用 的 字符 集 。 因 此 ， 如 果 在 
非 UTF-8 字 符 集 的 平台 中 录入 中 文 ， 需 要 用 下 面 的 指令 设置 录入 提交 
说 明 的 字符 集 ， 以 便 在 commit 对 象 中 藤 入 正确 的 编码 说 明 。 


$git config--system i1i8n.commitEncoding gbk 


同样 ， 为 了 让 带 有 中 文 文件 名 的 文件 在 工作 区 状态 输出 、 查 看 历 
史 更 改 概要 ， 以 及 在 补丁 文件 中 能 够 正常 显示 ， 要 为 Git 设 置 
core.quotepath 配 置 变量 ， 将 其 设置 为 false。 但 是 要 注意 ， 如 果 在 
msysGit 中 添加 文件 名 包含 中 文 的 文件 ， 就 只 能 在 msysGit 环 境 中 正确 
显示 ， 而 在 其 他 环境 (如 Linux、Mac OS X、Cygwin) 中 文件 名 会 显 
示 为 乱码 。 


$git config--system core.quotepath false 
$git status-s 
?3 说 明 .txt 


注意 ”如 果 同 时 安装 了 Cygwin 和 msysGit (可 能 配置 了 相同 的 用 户 
主 目录 ) ,或 者 因为 中 文 支持 问题 而 需要 单独 为 TortoiseGit 准 备 一 套 


msysGit 时 ， 为 了 保证 不 同 的 msysGit 之 间 ， 以 及 与 Cygwin 之 间 的 配置 
互 不 影响 ， 需 要 在 配置 Git 环 境 时 使 用 --system 参 数 。 这 是 因为 不 同 的 
msysGit 安 装 及 Cygwin 的 系统 级 配置 文件 的 位 置 不 同 ， 但 是 用 户 级 配置 
文件 的 位 置 却 可 能 重合 。 


3.4.5 ”使 用 SSH 人 协议 


msysGit 软 件 包 包含 的 ssh 命 令 和 Linux 下 的 ssh 命 令 没 有 什么 区 别 ， 
也 提供 ssh-keygen 命 令 管理 SSH 公 钥 / 私 钥 对 。 在 使 用 msysGit 的 ssh 命 令 
时 ， 没 有 遇 到 Cygwin 中 的 ssh 命 令 〈 版 本 号 : 5.7p1-1) 不 稳定 的 问题 ， 
即 msysGit 下 的 ssh 命 令 可 以 非常 稳定 地 工作 。 


如 果 需 要 与 Windows 更 好 地 整合 ， 硕 望 使 用 图 形 化 工具 管理 公 
钥 ， 也 可 以 使 用 PuTTY 提 供 的 plink.exe 作 为 SSH 客 户 端 。 关 于 如 何 使 用 
PuTTY， 请 参见 3.3.5 节 中 Cygwin 和 PuTTY 整 合 的 相关 内 容 。 


3.4.6 ”TortoiseGit 的 安装 和 使 用 


TortoiseGit 可 以 让 Git 与 Windows 资 源 管理 种 进行 整合 ， 为 Git 提 供 
了 图 形 化 操作 界面 。 像 其 他 Tortoise 系 列 产品 〈TortoiseCVS、 
TortoiseSVN) 一 样 ， 在 资源 管理 器 中 显示 的 Git 工 作 区 目录 和 文件 的 
图 标 附 加 了 标识 版 本 控制 状态 的 图 像 ， 这 样 可 以 非常 直观 地 看 到 哪些 
文件 被 更 改 了 并 需要 提交 。 通 过 扩展 后 的 右键 菜单 ， 可 以 非常 方便 地 
在 资源 管理 器 中 操作 Git 版 本 库 。 


TortoiseGit 是 对 msysGit 命 令 行 的 封装 ， 因 此 需要 先 安装 msysGit。 
灾 狼 TortoiseGit 非 常人 简单 ， 访 问 网 站 
http://code.google.com/p/tortoisegit/， 下 载 安 装 包 ， 然 后 根据 提示 完成 


Ee 


安装 过 程 中 会 询问 要 使 用 的 SSH 客 户 回 ， 如 图 3-23， 默 认 使 用 内 
置 的 TortoisePLink (来 自 PuTTY 项 目 ) 作为 SSH 客 户 端 。 


图 3-23 选择 SSH 客 户 端 


TortoisePLink 和 TortoiseGit 的 整合 性 更 好 ， 可 以 直接 通过 对 话 框 设 
置 SSH 私 钥 (PuTTY 格 式 ) ， 而 无 须 再 到 字符 界面 去 配置 SSH 私 钥 和 
其 他 配置 文件 。 如果 安 装 过 程 中 选择 了 OpenSSH， 可 以 在 安装 完 之 后 
通过 TortoiseGit 的 设置 对 话 框 重新 选择 TortoisePLink 作 为 默认 SSH 客 户 
端 ， 如 图 3-24 所 示 。 


3-24 更改 默认 SSH 客 户 端 


当 使 用 TortoisePLink 作 为 默认 的 SSH 客 户 端 后 ， 在 执行 克隆 操作 
时 ， 可 以 在 TortoiseGit 操 作 界 面 中 选择 一 个 PuTTY 格 式 的 私 钥 文件 进 
行 认 证 ， 如 图 3-25 所 示 。 


3-25 ”克隆 操作 选择 PuTTY 格 式 的 私 钥 文件 


如 果 需 要 更 换 连接 服务 器 的 SSH 私 钥 ， 可 以 通过 Git 远 程 服务 器 配 
置 界面 对 私 钥 文 件 进行 重新 设置 ， 如 图 3-26 所 示 。 


3-26 “更换 连接 远程 SSH 服 务 器 的 私 钥 


如 果 系统 中 安装 有 多 个 msysGit 的 拷贝 ， 可 以 通过 TortoiseGit 的 配 
置 界面 进行 选择 ， 如 图 3-27 所 示 。 


3-27 ”配置 msysGit 的 可 执行 程序 位 置 


3.4.7 ”TortoiseGit 的 中 文 支持 


虽然 TortoiseGit 在 底层 调用 了 msysGit， 但 是 TortoiseGit 的 中 文 文 持 
与 msysGit 是 有 区 别 的 。 前 面 在 介绍 msysGit 的 中 文 文 持 时 所 进行 的 配 
制 会 破坏 TortoiseGit 。 


TortoiseGit 在 提交 时 会 将 提交 说 明 转 换 为 UTF-8 字 符 集 ， 因 此 无 须 
对 i18n.commitEncoding 变 量 进行 设置 。 相 反 ， 如 采 将 
i18n.commitEncoding 设 置 为 gbk 或 其 他 字符 集 ， 则 在 提交 对 象 中 会 包含 
错误 的 编码 设置 ， 有 可 能 会 给 提交 说 明 的 显示 读 来 厅 烦 。 


TortoiseGit 在 显示 提交 说 明 时 认为 所 有 的 提交 说 明 都 是 UTF-8 编 
码 ， 会 转换 为 合适 的 Windows 本 地 字符 集 显 示 ， 而 无 须 设置 
i18n.logOutputEncoding 变 量 。 因 为 当前 版 本 的 TortoiseGit 没 有 对 提交 对 
象 中 的 encoding 设 置 进 行 检查 ， 所 以 使 用 GBK 字 符 集 的 提交 说 明 中 的 
中 文 不 能 正常 显示 。 


因此 ， 如 果 需 要 同时 使 用 msysGit 的 文字 界面 Git Bash 和 
TortoiseGit， 而 且 需 要 在 提交 说 明 中 使 用 中 文 ， 可 以 安装 两 套 
msysGit， 并 确保 TortoiseGit 关 联 的 msysGit 没 有 对 iL8n.commitEncoding 


进行 设置 。 


与 msysGit 一 样 ，TortoiseGit 对 使 用 中 文 命名 的 文件 和 目录 的 支 
持 ， 也 存在 缺陷 ， 因 此 应 当 避 人 免 在 msysGit 和 TortoiseGit 中 添加 用 中 文 
命名 的 文件 和 目录 ， 如 果 确 实 需 要 ， 可 以 使 用 Cygwin 。 


第 2 篇 ”Git 独 奏 


从 本 篇 开始 ， 我 们 天真 正 地 进入 到 Git 的 学 习 中 。Git 有 着 陡峭 的 
学 习 曲 线 ， 对 有 其 他 版 本 控制 工具 使 用 经 验 的 老手 也 不 例外 ， 因 为 他 
们 有 可 能 会 按照 在 其 他 版 本 控制 系统 中 遗留 的 习惯 去 操作 Git， 努 力 地 
在 Git 中 寻找 对 应 物 ， 最 终 会 因为 Git 的 “别扭 而 放弃 使 用 ， 这 也 是 我 的 
亲身 经 历 。 


Git 的 “别扭 ”部 分 源 目 于 传统 的 集中 式 版 本 控制 系统 与 以 Git 为 代表 
的 分 布 式 版 本 控制 系统 在 理念 上 的 巨大 差异 ， 部 分 是 因为 其 设计 者 
Linus Torvalds 对 Git 独 特 的 创新 式 设计 。“ 你 应 该 了 解 真 相 ， 真 相 会 使 
你 自由 ”由 ， 因 此 本 书 会 将 Git 的 设计 原理 渗透 到 每 一 个 章节 ， 让 您 通 
过 不 断 地 实践 、 思 考 、 再 实践 来 循序 渐进 地 掌握 Git 。 


本 篇 暂时 不 会 涉及 团队 如 何 使 用 Git 的 内 容 ， 而 是 先 从 个 人 的 角 厦 
去 探讨 如 何 用 好 Git。 本 篇 是 全 书 最 重要 的 部 分 ， 是 下 一 步 进 行 团队 协 
作 必 需 的 知识 准备 ， 也 是 理解 全 书 其 余 各 部 分 内 容 的 基础 。 到 本 篇 的 
结尾 时 ， 我 们 会 发 现 通 过 “Git 独 奏 ” 也 可 以 演绎 出 美妙 的 “乐曲 ”。 


第 4 章 ” ”Git 初始 化 


4.1 创建 版 本 库 太 第 一 次 提交 


您 当前 使 用 的 Git 是 1.5.6 版 或 更 高 的 版 本 吗 ? 通过 如 下 操作 来 查看 
一 下 您 的 Git 版 本 : 
$git--version 
git version 1.7.4 
Git 是 一 个 活跃 的 项 目 ， 仍 在 不 断 地 进化 之 中 ， 不 同 版 本 的 Git 功 
能 不 尽 相 同 。 本 书 对 Git 的 介绍 泗 盖 了 1.5.6 到 1.7.4 版 本 ， 这 也 是 目前 
Git 的 主要 版 本 。 如 果 您 使 用 的 Git 版 本 低 于 1.5.6， 那 么 请 升级 到 1.5.6 
或 更 高 的 版 本 。 本 书 示 例 使 用 的 是 1.7 版 本 的 Git， 我 们 会 尽 可 能 地 指出 
那些 与 低 版 本 不 兼容 的 命令 及 参数 。 


在 开始 Git 之 旅 之 前 ， 我 们 需要 设置 一 下 Git 的 配置 变量 ， 这 是 一 
次 性 的 工作 。 即 这 些 设置 会 在 全 局 文件 (用 户主 目录 下 的 .gitconfig) 
或 系统 文件 (如 /etc/gitconfig) 中 做 永久 的 记录 。 


(1) 告诉 Git 当 前 用 户 的 姓名 和 邮件 地 址 ， 配 置 的 用 户 名 和 邮件 
地 址 将 在 版 本 库 提交 时 用 到 。 


注意 ， 不 要 照抄 照搬 下 面 的 两 条 命令 ， 而 是 用 您 目 己 的 用 户 名 和 
邮件 地 址 代替 这 里 的 用 户 名 和 邮件 地 址 ， 否 则 您 的 劳动 成 果 (提交 内 
容 ) 可 就 要 算 到 我 的 头 上 了 。 


$git config--global user.name "Jiang Xin" 
$git config--global user.email jiangxin@ossxp.com 


(2) 设置 一 些 Git 别 名 ， 以 便 可 以 使 用 更 为 简洁 的 子 命令 


[© 


例如 : 输入 git ci 即 相 当 于 git commit， 输 入 git st 即 相当 于 git 


status ° 


如 果 拥 有 3 统管 理 
限 ) ， 厕 望 注册 的 命令 


$sudo 
$sudo 
$sudo 
$sudo 


git config--s 
git config--s 
git config--s 
git config--s 


里 员 权 限 (例如 通过 执行 sudo 命 令 获 取 管理 员 权 
别名 能 够 被 所 有 用 户 使 用 ， 可 以 执行 如 下 命 


ystem 
ystem 
ystem 
ystem 


也 可 以 运行 下 面 的 命令 ， 


$git 
$git 
$git 
$git 


config--global 
config--global 
config--global 
config--global 


alias. 
alias. 
alias. 
alias. 


alias. 
alias. 
alias. 
alias. 


st status 
ci commit 
co checkout 
br branch 


只 在 本 用 户 的 全 局 配置 中 添加 Git 命 令 别 


st status 
ci commit 
co checkout 
br branch 


(3) 在 Git 命 令 输出 中 开启 颜色 显示 。 


$git config--global color.ui true 


Git 的 所 有 操作 ， 


包括 创建 版 本 库 等 管理 操作 用 git 一 个 命令 即 可 完 


成 ， 不 像 其 他 版 本 控制 系统 (如 Subversion); ， 与 管理 相关 的 操作 要 使 


用 另外 的 命令 (如 svnadmin) 。 创 建 Git 版 本 库 ， 可 以 直接 进入 到 工作 
目录 中 ， 通 过 执行 git init 命 令 完 成 版 本 库 的 初始 化 。 


下 面 就 从 一 个 空 目录 开始 初始 化 版 本 库 ， 将 这 个 版 本 库 命 名 
为 "DEMO 版 本 库 ”， 这 个 DEMO 版 本 库 将 贯穿 本 篇 始终 。 为 了 方便 说 
明 ， 我 们 使 用 名 为 /path/to/my/workspace 的 目录 作为 个 人 的 工作 区 根 目 
录 ， 可 以 在 磁盘 中 创建 该 目录 并 设置 正确 的 权限 。 


目 先 建立 一 个 新 的 工作 目 隶 ， 进 入 该 目录 后 ， 执 行 git init 创 建 版 
本 库 。 


$cd/path/to/my/workspace 

$mkdir demo 

$cd demo 

$git init 

Initialized empty Git repository 
in/path/to/my/workspace/demo/ .git/ 


实际 上 ， 如 有 果 Git 的 版 本 征 1.6.5 或 更 新 的 版 本 ， 可 以 在 git init 命 令 
的 后 面 直接 输入 目 隶 名称 ， 目 动 完成 目录 的 创建 。 


$cd/path/to/my/workspace 

$git init demo 

Initialized empty Git repository 
in/path/to/my/workspace/demo/ .git/ 

$cd demo 


从 上 面 版 本 库 初 始 化 后 的 输出 中 可 以 看 到 ，git init 命 令 在 工作 区 
创建 了 隐藏 目 永 .git 。 


$1s-aF 
./../.g9it/ 


这 个 隐藏 的 .git 目 孙 就 是 Git 版 本 库 (又 叫 仓 库 ， repository) 9 


.git 有 版 本 库 所 在 的 目 孙 为 /pattyto/my/workspace/demo， 它 被 称 为 工 


作 区 ， 目 前 工作 区 除了 包含 一 个 隐藏 的 .git 版 本 库 目 录 外 空 无 一 物 。 


下 面 为 工作 区 中 加 点 料 : 在 工作 区 中 创建 一 个 文件 welcome.txt， 
内 容 就 是 一 行 "Hello."。 


$echo "Hello.">welcome.txt 


为 了 将 这 个 新 建立 的 文件 添加 到 版 本 库 ， 需 要 执行 下 面 的 命令 : 


$git add welcome.txt 


注意 ， 到 这 里 还 没有 完 。Git 和 大 部 分 其 他 版 本 控制 系统 一 样 ， 都 


JL 


需要 再 执行 一 次 提交 操作 ， 对 于 Git 来 说 就 是 执行 git commit 命 令 完成 


提交 。 在 提交 过 程 中 需要 输入 提交 说 明 ， 这 个 要 求 对 于 Git 来 说 古 强 制 
性 的 ， 不 像 其 他 很 多 版 本 控制 系统 (如 CVS 和 Subversion) 那样 接受 空 
日 的 提交 说 明 。 当 Git 提 交 时 ， 如 果 不 在 命令 行 提供 提交 说 明 (使 用 -m 
参数 ) ，Git 会 目 动 打开 一 个 编辑 器 ， 要 求 您 在 其 中 输入 提交 说 明 ， 和 输 
入 完毕 后 保存 并 退出 。 需 要 说 明 的 是 ， 读 者 要 在 一 定 程度 上 掌握 vim 


或 emacs (Linux 下 常用 的 两 种 编辑 器 ) 的 编辑 技巧 ， 否 则 保存 和 退出 
也 会 成 为 问题 。 


下 面 进 行 提交 。 为 了 说 明 方 便 ， 使 用 -m 参 数 直 接 给 出 了 提交 说 
明 。 
$git ci-m "initialized." 
[master(root-commit)78cde45|initialized. 


1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 welcome.txt 


从 上 面 的 命令 及 输出 中 可 以 看 出 : 


命令 git ci 实际 上 相当 于 git commit， 这 是 因为 之 前 为 Git 设 置 了 命 


通过 -m 参 数 设置 提交 说 明 为 : "initialized."。 


SN 


从 命令 输出 的 第 一 行 可 以 看 出 ， 此 次 提交 是 提交 在 名 为 master 的 
分 支 上 ， 且 是 该 分 支 的 第 一 个 提交 (root-commit) ， 提 交 ID 为 78cde45 


[2] 。 


从 命令 输出 的 第 二 行 可 以 看 出 ， 此 次 提交 修改 了 一 个 文件 ， 包 含 
一 行 的 搬入 。 


从 命令 输出 的 第 三 行 可 以 看 出 ， 此 次 提交 创建 了 新 文件 


welcome.txt ° 


[1] 圣经 《约翰 福音 8:32》。 

[2] 大 家 实际 操作 中 看 到 的 ID 肯定 和 这 里 写 的 不 一 样 ， 具 体 原 因 会 在 后 
面 的 6.1 节 中 予以 介绍 。 如 果 碰 巧 您 的 操作 也 显示 出 了 同样 的 ID 
(78cde45) ， 那 么 我 建议 您 赶紧 去 买 一 张 彩 票 。 


4.2 思考 : 为 什么 工作 区 根 目 邓 下 有 有 一 个 .git 目 采 


Git 及 其 他 分 布 式 版 本 控制 系统 (如 Mercuria/Hg、Bazaar) 的 一 个 
共同 的 显著 特点 是 ， 版 本 库 位 于 工作 区 的 根 目录 下 。 对 于 Git 来 说 ， 版 
本 库 位 于 工作 区 根 目录 下 的 .git 目 录 中 ， 且 仅 此 一 处 ， 在 工作 区 的 子 目 
录 下 则 没有 任何 其 他 跟 踩 文件 或 目录 。Git 的 这 种 设计 要 比 CVS 和 
Subversion 等 传统 的 集中 式 版 本 控制 工具 方便 多 了 。 


传统 的 集中 式 版 本 控制 系统 的 版 本 库 和 工作 区 是 分 开 的 ， 甚 至 是 
在 不 同 的 主机 上 ， 因 此 必须 建立 工作 区 和 版 本 库 的 对 应 。 下 面 来 看 看 
版 本 控制 系统 的 前 厘 们 是 如 何 建立 工作 区 和 版 本 库 的 跟 踊 的 ， 通 过 其 
各 目 设 计 的 优 缺 点 ， 我 们 会 更 深刻 地 体会 到 Git 实 现 的 必要 和 巧妙 。 


对 于 CVS 而 言 ， 工 作 区 的 根 目录 及 每 一 个 子 目录 下 都 有 一 个 CVS 
目 隶 ，CVS 目 杂 中 包含 几 个 配置 文件 ， 建 立 了 对 版 本 库 的 追踪 。 如 
CVS 目 录 下 的 Entries 文 件 记 录 了 从 版 本 库 检 出 到 工作 区 的 文件 的 名 
称 、 厂 本 和 时 间 玲 等， 通过 时 间 戳 的 对 比 可 快速 扫描 工作 区 文件 的 改 
动 。 这 样 设计 的 好 处 是 ， 可 以 将 工作 区 移动 到 任何 其 他 目 孙 中 ， 而 工 
作 区 和 版 本 控制 服务 万 的 映射 天 系 保 持 不 变 ， 这 样 工作 区 依然 能 够 正 
党 工作。 甚至 还 可 以 将 工作 区 的 某 个 子 目录 移动 到 其 他 位 置 ， 形 成 新 
的 工作 区 ， 在 新 的 工作 区 下 仍然 可 以 完成 版 本 控制 相关 的 操作 。 但 是 


缺点 也 很 多 ， 例 如 ， 如 有 果 工 作 区 文件 修改 了 ， 因 为 没有 原始 文件 做 比 
对 ， 所 以 向 服务 器 提交 修改 时 只 能 对 整个 文件 进行 传输 ， 而 不 能 仅 传 
输 文件 的 改动 部 分 ， 导 致 从 客户 端 到 服务 万 的 网 络 传输 效率 降低 。 还 
有 一 个 风险 是 信息 港 疡 ， 例 如 ，Web 服 务 器 的 目录 下 如 采 包 含 了 CVS 
目录 ， 黑 客 就 可 以 通过 扫描 CVS/Entries 文 件 得 到 目录 下 的 文件 列表 ， 
从 而 获得 他 们 想 要 的 信息 。 


对 于 Subversion 来 说 ， 工 作 区 的 根 目录 和 每 一 个 子 目录 下 都 有 一 
个 .svn 目 隶 。 目 隶 .svn 中 不 仅 包 含 了 类 似 于 CVS 的 跟踪 目录 下 的 配置 广 
件 ， 而 且 包 含 了 当前 工作 区 下 每 一 个 文件 的 拷贝 。 这 些 文件 的 原始 拷 
贝 让 某 些 SVN 于 命令 可 以 脱离 版 本 库 执 行 。 而 且 ， 当 由 客户 端 癌 服务 
絮 提 交 时 ， 可 以 只 提交 改动 的 部 分 ， 因 为 改动 的 文件 可 以 与 文件 的 原 
始 搁 贝 进行 差异 比较 。 但 是 ， 这 么 做 也 有 缺点 ， 除 了 会 像 CVS 那 样 因 
为 引入 CVS 跟 踩 目 了 永 而 有 可 能 造成 信息 洪 漏 外 ， 还 会 加 倍 占用 工作 区 
的 空间 。 此 外 ， 当 在 工作 区 目录 下 针对 文件 内 容 进 行 搜索 时 ， 会 因 
为 .svn 目 了 永 下 文件 的 原始 拷贝 导致 搜索 结 采 加 倍 ， 使 搜索 结 采 混乱 。 


有 的 版 本 控制 系统 在 工作 区 根本 束 没 有 任何 跟踪 文件 ， 例 如 ， 菜 
款 商 业 的 版 本 控制 软件 〈 就 不 点 名 了 ) 的 工作 区 就 非常 干 交 ， 没 有 任 
何 配置 文件 和 配置 目 示 。 但 是 ， 这 样 的 设计 更 糟糕 ， 因 为 它 实 际 上 是 
通过 服务 做 端 建立 文件 跟踪 ， 在 服务 硕 冰 的 数据 库 中 保存 了 一 个 包 合 
如 下 信息 的 表格 : 哪个 客户 端 ， 在 哪个 本 地 目录 检 出 了 哪个 版 本 的 版 


本 库 文 件 。 这 样 做 的 后 果 是 ， 如 果 客 户 端 将 工作 区 移动 或 改名 ， 允 会 
导致 文件 的 跟 蹊 状态 丢失 ， 从 而 出 现 文件 状态 未 知 的 问题 。 此 外 ， 客 
户 端 操 作 系统 重 凌 也 会 导致 文件 跟 踩 状态 丢失 。 


Git 这 种 将 版 本 库 放 在 工作 区 根 目录 下 的 设计 使 得 所 有 的 版 本 控制 
操作 (除了 与 其 他 远程 版 本 库 之 间 的 互 操 作 ) 都 在 本 地 即 可 完成 ， 不 
像 Subversion 只 有 窒 究 无 儿 的 几 个 命令 脱离 网 络 执行 。 而 且 ，Git 没 有 
CVS 和 Subversion 中 存在 的 安全 泄漏 问题 (只 要 保护 好 .git 目 录 ) ， 也 
不 会 像 Subversion 那 样 在 搜索 本 地 文件 时 出 现 搜 索 结 采 混乱 的 问题 。 甚 
至 ，Git 还 提供 了 一 条 git grep 命 令 来 更 好 地 搜索 工作 区 的 文件 内 容 ， 例 
如 ， 我 们 可 以 在 本 书 的 Git 库 中 执行 下 面 的 命令 来 搜索 版 本 库 中 的 文件 
内 


认 


$git grep "工作 区 文件 内 容 搜索 " 
02-git-solo/010-git-init.,rst:'git grep' 命 令 来 更 好 地 搜索 工作 区 的 文件 内 


Git 将 版 本 库 (.git 目 录 ) 放 在 工作 区 根 目录 下 ， 那 么 Git 的 相关 操 
作 一 定 要 在 工作 区 根 目 隶 下 执行 吗 ? 换 句 话说 ， 当 工作 区 中 包含 子 目 
录 ， 并 在 子 目 录 中 执行 Git 命 令 时 ， 如 何 定位 版 本 库 呢 ? 


实际 上 ， 当 在 Git 工 作 区 的 某 个 子 目录 下 执行 操作 的 时 候 ， 会 在 工 
作 区 目录 中 依次 同上 递归 查找 .git 目 录 ， 找 到 的 .git 目 录 就 古 工 作 区 对 


应 的 版 本 库 ，.git 所 在 的 目录 就 是 工作 区 的 根 目 录 ， 文 件 .gitindex 记 录 
了 工作 区 文件 的 状态 (实际 上 是 暂 存 区 的 状态 ) 。 


例如 ， 在 韭 Git 工 作 区 执行 git 命 令 时 会 因为 找 不 到 .git 目 录 而 报 


$cd/path/to/my/workspace/ 

$git status 

fatal:Not a git repository(or any of the parent 
directories):.git 


如 果 用 strace 中 命令 去 跟踪 执行 git status 命 令 时 的 人 磁盘 访问 ， 会 看 
到 沿 目 录 依 次 同上 递归 的 过 程 。 


$strace-e' trace=file' git status 


getcwd("/path/to/my/workspace",4096)=14 
stat(".",{st_ mode=S_IFDIR|O7S5S5, st_size=4096,...})=0 
stat(".git",OQOx7fffdf1288d0)=-1 ENOENT(No such file or directory) 
access(".git/objects",X OK)=-1 ENOENT(No such file or directory) 
access("./objects",X OK)=-1 ENOENT(No Such file or directory) 
stat("..",{st mode=S_IFDIR|QO755, st_size=4096,...})=0 
chdir("..")=0 
stat(".git",OQOx7fffdf1288d0)=-1 ENOENT(No such file or directory) 
access(".git/objects",X OK)=-1 ENOENT(No such file or directory) 
access("./objects",X OK)=-1 ENOENT(No Such file or directory) 
stat("..",{st mode=S_IFDIR|QO755, st_size=4096,...})=0 
chdir("..")=0 
stat(".git",OQOx7fffdf1288d0)=-1 ENOENT(No such file or directory) 
access(".git/objects",X OK)=-1 ENOENT(No Such file or directory) 
access("./objects",X OK)=-1 ENOENT(No such file or directory) 
fatal:Not a git repository(or any of the parent 
directories):.git 


当 在 工作 区 执行 Git 命 令 时 ， 上 面 碍 找 版 本 库 的 操作 总 是 默默 地 执 
行 ， 束 好 像 什么 也 没有 发 生 一 样 。 那 么 有 什么 办 法 知道 Git 版 本 库 的 位 
置 呢 ? 如 何 才能 知道 工作 区 的 根 目 录 在 哪里 呢 ? 可 以 用 Git 的 一 个 改 层 
命令 来 实现 ， 具 体操 作 过 程 如 下 : 


(1) 在 工作 区 中 建立 目录 a/b/c， 进 入 到 该 目录 中 。 


$cd/path/to/my/workspace/demo/ 
$mkdir-p a/b/c 
$cd/path/to/my/workspace/demo/a/b/c 


(2) 显示 版 本 库 .git 目 录 所 在 的 位 置 。 


$git rev-parse--git-dir 
/path/to/my/workspace/demo/ .git 


(3) 显示 工作 区 根 目录 。 


$git rev-parse--show-toplevel 
/path/to/my/workspace/demo 


(4) 相对 于 工作 区 根 目录 的 相对 目录 。 


$git rev-parse--show-prefix 
a/b/c/ 


(5) 显示 从 当前 目录 (cd) 后退 (up) 到 工作 区 的 根 的 深度 。 


$git rev-parse--show-cdup 
A A 


传统 的 集中 式 版 本 控制 系 统 的 工作 区 和 版 本 库 都 是 相 分 离 的 ， 像 
Git 这 样 把 版 本 库 目 录放 在 工作 区 古 不 古 太 不 安全 了 ? 


从 存储 安全 的 角度 上 来 讲 ， 将 版 本 库 放 在 工作 区 目录 下 有 点 “把 鸡 
蛋 闭 在 一 个 篮子 里 ”的 味道 。 如 有 果 征 记 了 工作 区 中 还 有 版 本 库 ， 当 直接 
从 工作 区 的 根 执行 目录 删除 操作 时 束 会 连 版 本 库 一 并 删除 ， 这 个 风险 
的 确 很 高 。 将 版 本 库 和 工作 区 拆 开 似乎 更 加 安全 ， 但 是 不 要 起 了 之 前 
的 讨论 ， 如 采 将 版 本 库 和 工作 区 拆 开 ， 束 要 引入 其 他 机 制 以 便 实现 版 
本 库 对 工作 区 的 追 踩 。 


Git 克 隆 可 以 降低 因为 版 本 库 和 工作 区 混杂 在 一 起 而 导致 的 版 本 库 
被 破坏 的 风险 。 可 以 通过 克隆 操作 在 本 机 男 外 的 人 磁盘 /目录 中 建 六 Git 
克隆 ， 并 在 工作 区 有 新 的 提交 时 ， 手 动 或 目 动 地 执行 网 克隆 版 本 库 的 
推送 (git push) 操作 。 如 果 使 用 网 络 协议 ， 还 可 以 实现 在 其 他 机 器 上 
建立 克隆 ， 这 样 就 更 安全 了 《〈 双 机 备份 ) 。 对 于 使 用 Git 做 版 本 控制 的 
团队 ， 每 个 人 都 是 一 个 备份 ， 因 此 团队 开发 中 的 Git 厂 本 库 更 安全 ， 管 
理 员 甚 至 无 须 顾虑 版 本 库存 储 的 安全 问题 。 


[1] Mac OS X 可 以 使 用 dtruss 命 令 。 


4.3 思考 : git config 命 令 的 各 参数 有 何 区 别 


在 之 前 出 现 的 git config 命 令 中 ， 有 的 使 用 了 --global 参 数 ， 有 的 使 
用 了 --system 参 数 ， 这 两 个 参数 有 什么 区 别 吗 ? 执行 下 面 的 一 系列 命令 
后 ， 您 整 会 明日 使 用 不 同 参数 的 git config 命 令 实 际 操作 的 文件 了 。 


执行 下 面 的 命令 ， 将 打开 /path/to/my/workspace/demo/.git/config 文 
件 进行 编辑 。 


$cd/path/to/my/workspace/demo/ 
$git config-e 


执行 下 面 的 命令 ， 将 打开 /home/jiangxin/.gitconfig (用 户主 目录 下 
的 .gitconfig 文 件 ) 全 局 配置 文件 进行 编辑 。 


$git config-e--global 


执行 下 面 的 命令 ， 将 打开 /etc/gitconfig 系 统 级 配置 文件 进行 编辑 。 
如 有 果 Git 安 洲 在 非 标准 位 置 ， 则 这 个 系统 级 的 配置 文件 也 可 能 是 在 男 外 
的 伍 置 * 


$git config-e--system 


Git 的 三 个 配置 文件 分 别 是 版 本 库 级 别 的 配置 文件 、 全 局 配置 文件 
(用 户主 目录 下 ) 和 系统 级 配置 文件 Wetc 目 未 下 ) 。 其 中 版 本 库 级 别 
的 配置 文件 的 优先 级 最 高 ， 全 局 配置 文件 次 之 ， 系 统 级 配置 文件 优先 
级 最 低 。 这 样 的 优先 级 设置 可 以 让 版 本 库 .git 目 录 下 的 config 文 件 中 的 
配置 履 盖 用 户主 目录 下 的 Git 环 境 配置 ， 而 用 户主 目录 下 的 配置 也 可 以 
和 窗 盖 系统 的 执行 前 面 的 三 个 git config 命 令 后 会 看 到 这 三 个 级 别 的 配置 
文件 的 格式 和 和 内容， 原来 Git 配 置 文件 采用 的 是 IN 文件 格式 。 示 例如 
下 


$cat/path/to/my/workspace/demo/ .git/config 
[core] 

repositoryformatversion=0 

filemode=true 

bare=false 

logallrefupdates=true 


git config 命 令 可 以 用 于 读 取 和 更 改 INI 配 置 文件 的 内 容 。 使 用 只 融 
一 个 参数 的 git config < section > .<key> 命令 可 用 来 读 取 INI 配 置 文件 
中 某 个 配置 的 键 值 ， 例 如 读 取 [core] 小 节 的 bare 的 属性 值 ， 可 以 用 如 下 


分 ~、 人 
命令 : 


$git config core.bare 
false 


如 采 想 更 改 或 设置 INI 文 件 中 茶 个 属性 的 值 也 非常 简单 ， 命 令 格式 
是 : git config< section>.<key> <value>。 可 以 用 如 下 探 作 : 


$git config a.b something 
$git config x.y.z others 


如 果 打 开 .git/config 文 件 ， 会 看 到 如 下 内 容 : 


[aj 
b=something 
[x"y"] 
z=others 


对 于 类 似 于 [x "y"] 这 样 的 配置 小 节 会 在 本 书 第 三 篇 介绍 远程 版 本 
库 的 章节 中 经 常 遇 到 。 


从 上 面 的 介绍 中 可 以 看 到 ， 使 用 git config 命 令 可 以 非常 方便 地 操 
作 INI 文 件 ， 实 际 上 可 以 用 git config 命 令 操作 任何 其 他 的 INI 文 件 。 


向 配置 文件 test,ini 中 添加 配置 。 


$GIT_CONFIG=test.ini git config a.b.c.d "hello,world" 


从 配置 文件 test.ini 中 读 取 配置 。 


$GIT_CONFIG=test.ini git config a.b.c.d 
hello,world 


后 面 介绍 的 git-svn 和 Gistore 等 软件 加 是 使 用 该 技术 读 写 各 目 专 有 
的 配置 文件 的 。 


4.4 思考 : 是 谁 完成 的 提交 


在 本 章 的 一 开始 先 为 Git 设 置 了 全 局 配置 变量 username 和 
useremail， 如 果 不 设 置 会 有 什么 结果 呢 ? 


执行 下 面 的 命令 ， 删 除 Git 全 局 配置 文件 中 关于 username 和 


Useremail 的 设置 


$git config--unset--global user.name 
$git config--unset--global user.email 


这 样 一 来 ， 关 于 用 户 姓名 和 邮件 的 设置 都 被 清空 了 ， 执 行 下 面 的 
命令 将 看 不 到 输出 。 


$git config User ,name 
$git config user.email 


下 面 再 笑 试 一 次 提交 ， 看 看 提交 的 过 程 会 有 什么 不 同 ， 以 及 提交 
之 后 显示 的 提交 者 是 谁 ? 


在 下 面 的 命令 中 使 用 了 --allow-empty 参 数 ， 这 是 因为 如 果 没 有 对 
工作 区 的 文件 进行 任何 修改 ，Git 默 认 不 会 执行 提交 ， 使 用 --allow- 
empty 参 数 后 允许 执行 至 日 提交 ， 操 作 如 下 : 


$cd/path/to/my/workspace/demo 


$git commit--allow-empty-m "who does commit? " 

[master 252dc53]who does commit? 

Committer:JiangXin<jiangxin@hp.moon.ossxp.com> 

Your name and email address were configured automatically based 

on your username and hostname.Please check that they are 
accurate. 

You can suppress this message by setting them explicitly: 

git config--global user.name "Your Name" 

git config--global user.email]l youQ@example.com 

If the identity used for this commit is wrong,you can fix it 
with: 

git commit--amend--author='Your Name<you@example.com> 


喔 ， 因 为 没有 设置 配置 变量 username 和 useremail， 提 交 后 输出 乱 
得 一 塌 糊 涂 。 仔 细 看 看 上 面 的 执行 git commit 命 令 后 的 输出 ， 原 来 Git 
提供 了 详细 的 帮助 来 告诉 我 们 如 何 设置 必需 的 配置 变量 ， 以 及 如 何 修 
改 之 前 提交 中 出 现 的 错误 的 提交 者 信息 。 


如 果 此 时 查看 版 本 库 的 提交 日 志 ， 会 看 到 有 两 次 提交 。 


注意 ， 下 面 的 输出 与 你 动手 实践 时 得 到 的 输出 肯定 有 所 不 同 ， 一 
方面 因为 提交 时 间 会 不 一 样 ， 另 外 一 方面 因为 由 40 位 十 六 进 制 数字 组 
成 的 提交 ID 也 不 可 能 一 样 。 甚 至 ， 本 书 中 凡是 您 亲 目 完成 的 提交 ， 相 
关 的 40 位 魔幻 般 的 数字 ID 也 都 会 不 一 样 \ 原 因 会 在 后 面 的 章节 中 看 
到 ) 。 因 此 ， 凡 是 涉及 数字 ID 和 本 书 中 的 示例 不 一 致 的 时 候 ， 以 你 目 
己 的 数字 ID 为 准 ， 本 书 提供 的 示例 仅 供 参考 ， 切 记 。 


$git 1og--pretty=fuller 

commit 252dc539b5b5f9683edd54849c8e0a246e88979c 
Author:JiangXin<jiangxin@hp.moon.ossxp.com> 
AuthorDate:Mon Nov 29 10:39:35 2010+0800 
Commit:JiangXin<jiangxin@hp.moon.ossxp.com> 


CommitDate:Mon Nov 29 10:39:35 2010+0800 

who does commit? 

commit 9e8a761ff9dd343a1380032884f488a2422c495a 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Sun Nov 28 12:48:26 2010+0800 
Commit:Jiang Xin<]jiangxin@ossxp.com> 
CommitDate:Sun Nov 28 12:48:26 2010+0800 
initialized. 


最 早 的 提交 (提交 ID 为 9e8a761..…….) ， 提 交 者 的 信息 是 由 之 前 设 
置 的 配置 变量 username 和 useremail 给 出 的 。 而 最 新 的 提交 《提交 ID 为 
252dc53......) 因为 删除 了 username 和 useremail， 提 交 时 Git 对 提交 者 
的 用 户 名 和 邮件 地 址 进行 了 大 胆 的 猜测 ， 这 个 猜测 可 能 是 错 的 。 


为 了 保证 提交 时 提交 者 和 作者 信息 的 正确 性 ， 需 要 重新 恢复 
username 和 useremail 的 设置 。 记 住 ， 不 要 照抄 照搬 下 面 的 命令 ， 请 使 
用 您 自己 的 用 户 名 和 邮件 地 址 。 


$git config--global user.name "Jiang Xin" 
$git config--global user.email jiangxin@ossxp.com 


然后 执行 下 面 的 命令 ， 重 新 修改 最 新 的 提交 ， 改 正 作 者 和 提交 者 


的 错误 信息 。 


$git commit--amend- -allow-empty--reset-author 


说 明 : 


参数 --amend 是 对 刚刚 的 提交 进行 修补 ， 这 样 就 可 以 改正 前 面 的 提 
交 中 错误 的 用 户 名 和 邮件 地 址 ， 而 不 会 产生 另外 的 新 提交 。 


参数 --allow-empty 使 得 空 日 提交 被 允许 。 之 所 以 这 里 必须 使 用 此 


参数 古 因为 要 进行 的 修补 提交 实际 上 是 一 个 空 日 提交 。 


参数 --reset-author 的 含义 是 将 Author (提交 者 ) 的 ID 同步 修改 ， 否 


则 只 会 影响 提交 者 (Commit) 的 ID。 使 用 此 参数 也 会 重 置 AuthorDate 


通过 日 志 可 以 看 到 ， 最 新 提交 的 作者 和 提交 者 的 信息 已 经 改正 
了 。 


$git 1og--pretty=fuller 

commit ao0c641e92b10d8bccaled1bf84ca80340fdefee6 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Mon Nov 29 11:00:06 2010+0800 

Commit :Jiang Xin<jiangxin@ossxp.com> 
CommitDate:Mon Nov 29 11:00:06 2010+0800 

who does commit? 

commit 9e8a761ff9dd343a1380032884f488a2422c495a 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Sun Nov 28 12:48:26 2010+0800 
Commit:Jiang Xin<jiangxin@ossxp.com> 
CommitDate:Sun Nov 28 12:48:26 2010+0800 
initialized. 


4.5 ”思考 : 随意 设置 提交 者 姓名 ， 有 是 否 太 不 安全 


使 用 过 CVS 和 Subversion 等 集中 式 版 本 控制 系统 的 用 户 都 知道 ， 
次 提交 的 时 候 需 要 认证 ， 认 证 成 功 后 ， 登 录 ID 束 作为 提交 者 ID 出 现在 
版 本 库 的 提交 日 志 中 。 很 显然 ， 对 于 CVS 和 Subversion 这 样 的 版 本 控制 
系统 而 言 ， 很 难 冒 充 他 人 提交 。 像 Git 这 样 的 分 布 式 版 本 控制 系统 ， 
以 随心 所 欲 地 设 定 提 交 者 ， 这 似乎 太 不 安全 了 。 


Git 可 以 随意 设置 提交 的 用 户 名 和 邮件 地 址 信息 ， 这 是 分 布 式 版 本 
控制 系统 的 特性 使 然 ， 每 个 人 痢 是 目 己 版 本 库 的 主人 ， 很 难 也 没有 必 
要 进行 喘 份 认证 ， 因 而 也 整 无 法 使 用 经 过 认证 的 用 户 名 作为 提交 的 用 
a 


在 进行 “独奏 ”的 时 候 ， 还 要 强制 为 目 己 加 上 一 个 “指纹 识别 *”， 实 在 
是 太 没 有 必要 了 ， 但 是 团队 合作 时 授权 就 成 为 必需 了 。 通 币 ， 团 队 协 
作 时 会 设置 一 个 共享 版 本 库 ， 在 团队 成 员 向 共享 版 本 库 传 送 (推送 ) 
新 提交 时 ， 会 进行 用 户 身份 认证 并 检查 授权 。 一 旦 用 户 通过 身份 认 
证 ， 一 般 来 说 不 会 对 提交 中 的 包含 的 提交 者 ID 做 进一步 检查 ， 但 
Android 项 目 是 个 例外 。 


Android 项 目 为 了 更 好 地 使 用 Git 实 现 对 代码 的 集中 管理 ， 开 发 了 一 
套 叫 作 Gerrit 的 审核 服务 器 来 管理 Git 提 交 ， 对 提交 者 的 邮件 地 址 进行 审 


核 。 例 如 下 面 的 示例 中 ， 在 向 Gerrit 服 务 器 推送 的 时 候 ， 提 交 中 的 提交 
者 邮件 地 址 为 jiangxin@ossxp.com， 但 是 在 Gerrit 中 注册 用 户 时 使 用 的 邮 
件 地 址 为 jiangxin@moon.ossxp.com。 因 为 两 者 不 匹配 ， 从 而 导致 推送 
失败 。 

$git push origin master 

Counting objects:3,done. 

Writing objects:100%(3/3),222 bytes, done. 

Total 3(delta 0),reused 0(delta 0) 

To ssh://localhost:29418/new/project.git 

![remote rejected]jmaster->master(you are not committer 
jiangxin@ossxp.com) 


error:failed to push some refs to 
'ssh://localhost:29418/new/project .git'" 


即使 没有 使 用 类 似 Gerrit 的 服务 ， 作 为 提交 者 也 不 应 该 随意 改变 配 
置 变量 username 和 useremail 的 设置 ， 因 为 当 多 人 协同 时 这 样 做 会 给 他 
人 造成 迷惑 ， 也 会 给 一 些 项 目 管理 软件 造成 磋 烦 。 


例如 ，Redmine 是 一 款 实 现 需 求 管理 和 缺陷 跟踪 的 项 目 管理 软件 ， 
可 以 与 Git 版 本 库 实现 整合 。Git 的 提交 可 以 直接 关闭 Redmine 上 的 Bug， 
同时 Git 的 提交 还 可 以 反映 出 项 目 成 员 的 工作 进度 。Redmine 中 的 用 户 
(项 目 成 员 ) 用 一 个 ID 作 标识 ， 而 Git 的 提交 者 则 用 一 个 包含 用 户 名 和 
邮件 地 址 的 字符 串 ， 如 何 将 Redmine 的 用 户 和 Git 的 提交 者 相关 联 呢 ? 
Redmine 提 供 了 一 个 配置 界面 用 于 设置 二 者 之 间 的 映射 ， 如 图 4-1 所 
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图 4-1 Redmine 中 用 户 ID 和 Git 覃 交 者 关联 


显然 ， 如 有 果 在 Git 提 区 时 随意 变更 提交 者 的 姓名 和 邮件 地 址 ， 束 会 
破坏 Redmine 软 件 中 设置 好 的 用 户 对 应 关系 。 


4.6 思考 : 命令 别名 十 干什么 的 


在 本 章 的 一 开始 ， 我 们 通过 对 alias .ci 等 Git 配置 变节 的 设置 为 Git 设置 了 命令 别 
名 。 命令 别名 可 以 帮助 用 户 解决 从 其 他 版 本 控制 系统 迁移 到 Git 后 的 使 用 习惯 问题 。CVS 和 
Subversion 等 在 提交 的 时 候 ， 一 般 习 惯 使 用 ci (check in) 子 命令 ， 在 检 出 的 有 时候 则 习惯 使 
用 cc (check out) 子 命令 。 如 果 Git 不 能 提供 对 ci 和 cc 这 类 简洁 命令 的 支持 ， 对 于 拥有 
其 他 版 本 控制 系统 使 用 经 验 的 用 户 来 说 ，Git 的 用 户 体 检 就 会 打折 扣 。 幸 好 聪明 的 Git 提供 了 
别名 机 制 ， 可 以 满 吓 用 户 特殊 的 使 用 习惯 。 

本 章 前 面 列 出 的 四 条 别名 设置 指令 ， 创 建 的 是 最 常用 的 几 个 Git 别名 。 实 际 上 别名 还 可 
以 包含 命令 参数 ， 例 如 下 面 的 别名 设置 指令 ， 


$s git config -~global alias.ci "commit ~s" 
如 上 设置 后 ， 当 使 用 git ci 命令 提交 时 ， 会 目 动 珊 上 -s 参 数 ， 这 样 
会 在 提交 说 明 中 目 动 添加 上 包含 提交 者 姓名 和 邮件 地 址 的 签名 标识 。 
类 似 于 Signed-off-by:User Name <email@address >>。 这 对 于 一 些 项 目 
(Git、Linux kernel、Android 等 ) 来 说 是 必要 甚至 是 必需 的 。 


不 过 ， 本 书 会 尽量 避免 使 用 别名 命令 ， 以 免 由 于 您 因为 尚未 设置 
别名 而 造成 困扰 。 


4.7 备份 本 章 的 工作 成 末 


执行 下 面 的 命令 ， 算 是 对 本 章 工作 成 果 的 备份 : 


$cd/path/to/my/workspace 
$git clone demo demo-step-1 
Cloning into demo-step-1... 
done. 


第 5 章 ”Git 和 暂 存 区 


上 一 章 主要 学 习 了 三 个 命令 ，git init、git add 和 git commit， 这 三 
个 命令 可 以 说 是 版 本 库 创 建 的 三 部 曲 。 同 时 还 通过 对 几 个 问题 的 思考 
了 解 了 Git 版 本 库 在 工作 区 中 的 布局 ，Git 三 个 等 级 的 配置 文件 及 Git 的 


别名 命令 等 内 容 。 


在 上 一 章 的 实践 中 ，DEMO 版 本 库 经 历 了 两 次 提交 ， 可 以 用 git log 
查看 提交 日 志 (附加 的 --stat 参 数 可 以 看 到 每 次 提交 的 文件 变更 统 
计 ) 。 


$cd/path/to/my/workspace/demo 

$git 1og--Stat 

commit ao0c641e92b10d8bccaled1bf84ca80340fdefee6 Author:Jiang Xin 
<jiangxin@ossxp.com> 

Date:Mon Nov 29 11:00:06 2010+0800 

who does commit? 

commit 9e8a761ff9dd343a1380032884f488a2422c495a 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Sun Nov 28 12:48:26 2010+0800 

initialized. 

welcome.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 


可 以 看 到 第 一 次 (最 早 的 提交 对 文件 welcome.txt 有 一 行 变更 ， 
而 第 二 次 (最 新 的 ) 提交 因为 是 使 用 --allow-empty 参 数 进行 的 一 次 空 
提交 ， 所 以 提交 说 明 中 看 不 到 任何 对 实质 内 容 的 修改 。 


下 面 我 们 将 仍 在 这 个 工作 区 继续 新 的 实践 和 学 习 ， 以 擎 握 Git 的 一 
个 最 重要 概念 ， 和 暂 存 区 。 


5.1 ”修改 不 能 直接 提交 蚂 


首先 更 改 welcome.txt 文 件 ， 在 这 个 文件 后 面 退 加 一 行 。 可 以 使 用 
下 面 的 命令 实现 内 容 的 追加 : 


$echo "Nice to meet you."> >welcome.txt 


这 时 可 以 通过 执行 git diff 命 令 看 到 修改 后 的 文件 与 版 本 库 中 的 文 
件 的 差异 。 《实际 上 这 句 话 有 问题 ， 与 本 地 比较 的 不 是 版 本 库 中 的 文 
作 ， 面 是 二 不下 同 大 全 的 区 人) 


$git diff 

diff--git a/welcome.txt b/welcome.txt 
index 18832d3. .fd3c069 100644 
---a/welcome.txt 

+++b/welcome .txt 

@@-1+1, 200 

Hello. 

+Nice to meet you. 


对 差异 输出 是 不 是 很 熟悉 ? 在 之 前 介绍 版 本 库 的 “黑暗 的 史前 时 
代 ” 时 ， 曾 经 展示 了 diff 命 令 的 输出 ， 两 者 的 格式 古 一 样 的 。 


既然 文件 修改 了 ， 那 么 束 提 交 吧 。 拓 交 能 够 成 功 吗 ? 


$git commit-m "Append a nice line." 

#0n branch master 

#Changes not staged for commit: 

#(USe "git add<file>..."to update what will be committed) 

#(USe "git checkout--<file>..."to discard changes in working 
directory) 

# 

#modified:welcome.txt 

# 

no changes added to commit(use "git add" and/or "git commit-a") 


是 交 成 功 了 吗 ? 好 像 没 有 


提交 没有 成 功 的 证 据 : 


(1) 先 来 看 看 提交 日 志 ， 如 果 提 交 成 功 ， 应 该 有 新 的 提交 记录 出 
现 。 


下 面 使 用 了 精简 输出 来 显示 日 志 ， 以 便 更 简洁 和 清晰 地 看 到 提交 
的 历史 。 从 其 中 能 够 看 出 版 本 库 中 只 有 两 个 提交 ， 都 是 在 上 一 章 的 实 
践 中 完成 的 。 也 就 是 说 ， 刚 才 针 对 修改 文件 的 提交 没有 成 功 ! 

$git 10g--pretty=oneline 


a0c641e92b1i0d8bccaled1ibf84ca80340fdefee6 who does commit? 
9e8a761ff9dd343a1380032884f488a2422c495a initialized. 


(2) 执行 git diff 可 以 看 到 与 之 前 相同 的 差异 输出 ， 这 也 说 明了 之 
前 的 提交 没有 成 功 。 


(3) 执行 git status 查 看 文件 状态 ， 可 以 看 到 文件 处 于 修改 状态 ， 
而 且 git status 命 令 的 输出 和 git commit 提 区 失败 的 输出 信息 完全 一 样 ! 


(4) 对 于 习惯 了 像 CVS 和 Subversion 那 样 精简 的 状态 输出 的 用 
户 ， 可 以 在 执行 git status 时 附加 上 -s 参 数 ， 显 示 精 简 格式 的 状态 输出 。 


$git status-s M welcome.txt 


提交 为 什么 会 失败 呢 ? 再 回 过 头 来 仔细 看 看 刚才 git commit 命 令 提 
交 失 败 后 的 输出 : 


#0n branch master 
#Changes not staged for commit: 


#(USe "git add<file>..."to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 


#modified:welcome.txt 
# 
no changes added to commit(use "git add" and/or "git commit-a") 


把 筷 翻 译 成 中 文 则 是 : 


# 位 于 您 当前 工作 的 分 支 master 上 
# 下 列 修改 还 没有 加 入 到 提交 任务 (提交 暂 存 区 , stage ) 中 , 不 会 被 提交 
#( 使 用 "git add<file> ..." 命 令 后 ,了 改动 就 会 加 入 到 提交 任务 中 ， 


# 要 在 一 次 提交 操作 时 才 被 提交 ] 

#( 使 用 "git checkout--<file>. . . "命令 ,工作 区 中 当前 您 不 打算 
# 提 交 的 修改 会 被 彻底 清除 ! ) 

# 

# 已 修改 :welcome. txt 

# 


警告 :提交 任务 是 空 的 呆 , 您 不 要 再 反 扰 我 啦 ( 除 非 使 用 
"git add" 和 /或 "git commit-a" 命 令 ) 


也 就 是 说 ， 需 要 对 修改 的 welcome.txt 文 件 执行 git add 命 令 ， 将 修 
改 的 文件 添加 到 “提交 任务 中， 然后 才能 提交 ! 


这 个 行为 真 的 很 奇怪 ， 对 于 其 他 版 本 控制 系统 来 说 执行 add 操 作 厦 
向 版 本 库 中 添加 新 文件 用 的 ， 修 改 的 文件 (已 被 版 本 控制 跟踪 的 文 
件 ) 在 下 次 提交 时 会 直接 被 提交 。Git 的 这 个 古怪 的 行为 会 在 下 面 的 介 
绍 中 得 到 解释 ， 大 家 会 逐渐 习惯 并 喜欢 Git 的 这 个 设计 。 


好 了 ， 现 在 束 将 修改 的 文件 “添加 ”到 提交 任务 中 吧 : 


$git add welcome.txt 


现在 再 执行 一 些 Git 命 令 ， 看 看 当 执行 完 “ 添 加 ”操作 后 ，Git 库 发 生 
村 村 公 概 | 


执行 git diff 没 有 和 输出， 难道 是 被 提交 了 ? 可 征 只 是 执行 了 *“ 添 
加 ”到 提交 任务 的 操作 ， 相 当 于 一 个 “登记 ”的 命令 ， 并 没有 执行 提交 


哇 ? 


$git diff 


这 时 如 果 与 HEAD 《当前 版 本 库 的 头 指针 ) 或 master 分 支 (当前 工 
作 分 支 ) 进行 比较 ， 就 会 发 现 有 差异 。 这 个 差异 才 是 正常 的 ， 因 为 尚 
未 真正 提交 嘛 。 


$git diff HEAD 

diff--git a/welcome.txt b/welcome.txt 
index 18832d3. .fd3c069 100644 
---A/welcome.txt 

+++b/welcome .txt 


Q@@-1+1, 2@@ 
Hello. 
+Nice to meet you. 


执行 git status 命 令 ， 状 态 输 出 和 之 前 的 不 一 样 了 。 


$git status 
#0n branch master 
#Changes to be committed: 


#(USe "git reset HEAD<file>..."to unstage) 
## 

#modified:welcome.txt 

## 


再 对 新 的 Git 状 态 输 出 进行 翻译 : 


$git status 

# 位 于 分 支 master 上 

# 下 列 修改 将 被 提交 : 

#( 如 果 你 后 悔 了 , 可 以 使 用 "git reset HEAD<file>... "命令 
# 将 下 列 改动 撤 出 提交 任务 (提交 暂 存 区 , stage)，, 否则 执行 提交 命令 
# 可 真 的 要 提交 里 ) 


# 
# 已 修改 :welcome .txt 
# 


不 得 不 说 ，Git 太 人 性 化 了 ， 它 把 各 种 情况 下 可 能 使 用 到 的 命令 都 
告诉 给 用 户 了 ， 虽 然 这 显得 有 点 哆 嗪 。 如 采 不 要 这 么 哆 嗪 ， 可 以 像 下 
面 这 样 用 简洁 的 方式 显示 状态 : 


$git status-s 
M welcome.txt 


上 面 的 精简 状态 输出 与 执行 git add 之 前 的 精简 状态 输出 相 比 ， 有 
细微 的 差别 ， 发 现 了 吗 ? 


虽然 都 是 M (Modified) 标识 ， 但 是 位 置 不 一 样 。 在 执行 git add 命 
令 之 前 ， 这 个 M 位 于 第 二 列 (第 一 列 是 一 个 空格 ) ， 在 执行 完 git add 
之 后 ， 字 符 M 位 于 第 一 列 (第 二 列 是 空白 ) 。 


位 于 第 一 列 的 字符 M 的 舍 义 是 : 版 本 库 中 的 文件 与 处 于 中 间 状 态 
一 一 提交 任务 (提交 和 暂 存 区 ，stage) 中 的 文件 相 比 有 改动 。 


位 于 第 二 列 的 字符 M 的 含义 是 ， 工 作 区 当前 的 文件 与 处 于 中 间 状 
提交 任务 〈 提 交 暂 存 区 ，stage) 中 的 文件 相 比 有 改动 。 


太 
4UD 


苹 不 是 还 有 一 些 不 明白 ?为 什么 Git 的 状态 输出 中 提示 了 那么 多 让 
人 不 解 的 命令 ? 为 什么 存在 一 个 提交 任务 的 概念 而 又 总 是 把 它 叫 作 暂 
存 区 (stage) ? 不 要 紧 ， 马 上 就 会 专题 讲述 “ 暂 存 区 ”的 概念 。 当 了 解 
了 Git 版 本 库 的 设计 原理 之 后 ， 理 解 相 关 Git 命 令 就 易如反掌 了 。 


这 时 如 果 直 接 提交 (git commit) ， 加 入 提交 任务 的 welcome.txt 文 
件 的 更 改 就 会 被 提交 入 库 了 。 但 是 先 不 忙 着 执行 提交 ， 再 执行 一 些 操 
作 ， 看 看 是 否 会 被 彻底 地 搞 糊 涂 。 


(1) 继续 修改 一 下 welcome.txt 文 件 (在 文件 后 面 再 追加 一 行 。 


$echo "Bye-Bye."> >welcome.txt 


(2) 然后 执行 git status， 查 看 一 下 状态 : 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
# 


#modified:welcome.txt 

# 

#Changes not staged for commit: 

#(USe "git add<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 

#modified:welcome.txt 

# 


状态 输出 大 然 是 之 前 出 现 的 两 种 不 同 状 态 输 出 的 杂 合 体 。 


(3) 如 果 显 示 精 简 的 状态 输出 ， 也 会 看 到 前 面 两 种 精简 输出 的 杂 
合体 。 


$git status-s 
MM welcome.txt 


上 面 的 更 为 复杂 的 Git 状 态 输 出 可 以 这 么 理解 :不 但 版 本 库 中 最 新 
提交 的 文件 与 处 于 中 间 状 态 一 一 提交 任务 (提交 和 暂 存 区 ，stage) 中 的 
文件 相 比 有 改动 ， 而 且 工 作 区 当前 的 文件 与 处 于 中 间 状 态 一 一 提交 任 

务 (提交 暂 存 区 ，stage) 中 的 文件 相 比 也 有 改动 。 


即 现在 welcome.txt 有 三 个 不 同 的 版 本 ， 一 个 在 工作 区 ， 一 个 在 等 
竺 提交 的 暂 存 区 ， 还 有 一 个 是 版 本 库 中 最 新 版 本 的 welcome.txt。 通 过 
不 同 的 参数 调用 git diff 命 令 可 以 看 到 不 同 状态 下 welcome.txt 文 件 的 差 


异 。 


(1) 不 带 任 何 选 项 和 参数 调用 git dif 显 示 工 作 区 的 最 新 改动 ， 即 
工作 区 与 提交 任务 (提交 暂 存 区 ，stage) 中 相 比 的 差异 。 


$git diff 

diff--git a/welcome.txt b/welcome.txt 
index fd3c069..51dbfd2 100644 
---a/welcome.txt 

+++b/welcome .txt 

QQ@-1, 2+1, 300 

Hello. 

Nice to meet you. 

+Bye -Bye. 


(2) 将 工作 区 和 HEAD (当前 工作 分 支 ) 相 比 ， 会 看 到 更 多 的 差 


站 


$git diff HEAD 

diff--git a/welcome.txt b/welcome.txt 
index 18832d3..51dbfd2 100644 
---a/welcome.txt 

+++b/welcome .txt 

@@-1+1, 300 

Hello. 

+Nice to meet you. 

+Bye -Bye. 


(3) 通过 参数 --cached 或 -staged 调 用 git diff 命 令 ， 看 到 的 是 提交 
暂 存 区 (提交 任务 ，stage) 和 版 本 库 中 文件 的 差异 。 


$git diff--cached 

diff--git a/welcome.txt b/welcome.txt 
index 18832d3. .fd3c069 100644 
---a/welcome.txt 

+++b/welcome .txt 

@@-1+1, 2@0 

Hello. 

+Nice to meet you. 


好 了 ， 现 在 是 时 候 所 区 了 “。 执 行 git commit 命 令 进行 提交 : 


$git commit-m "which version checked in?" 
[master e695606]which version checked in? 
1 files changed,1 insertions(+),0 deletions(-) 


这 次 提交 终于 成 功 了 。 如 何 证 明 提 交 成 功 了 呢 ? 


(1) 通过 查看 提交 日 志 ， 看 到 了 新 的 提交 : 


$git lo0g--pretty=oneline 

e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked 
in? 

a0c641e92b1i0d8bccaled1ibf84ca80340fdefee6 who does commit? 

9e8a761ff9dd343a1380032884f488a2422c495a initialized. 


(2) 查看 精简 的 状态 输出 。 


状态 输出 中 ， 文 件 名 的 前 面 少 了 一 个 字母 M， 即 只 剩 下 第 二 列 的 
字母 M。 那 么 第 一 列 的 M 哪 里 去 了 ? 被 提交 了 喘 。 即 提交 任务 (提交 


暂 存 区 ，stage) 中 的 内 容 被 提交 到 版 本 库 中 。 所 以 ， 第 一 列 会 因为 提 
交 暂 存 区 (提交 任务 ，stage) 与 版 本 库 中 的 状态 一 致 而 显示 一 个 空 
= 


$git status-s 
M welcome.txt 


提交 的 welcome.txt 是 哪个 版 本 呢 ? 可 以 通过 执行 git diff 或 git diff 
HEAD 命 令 查看 差异 。 虽 然 命令 git dif 和 git diff HEAD 的 比较 过 程 并 不 
相同 (可 以 通过 strace 命 令 跟踪 命令 执行 过 程 中 的 文件 访问 ) ， 但 是 会 
看 到 如 下 面 所 示 的 相同 的 差异 输出 结 


$git diff 

diff--git a/welcome.txt b/welcome.txt 
index fd3c069. .51dbfd2 100644 
---a/welcome. txt 

+++b/welcome .txt 

@@-1,2+1, 3@@ 

Hello. 

Nice to meet you. 

+Bye -Bye. 


5.2 理解 Git 暂 存 区 (stage) 


将 上 面 的 实践 从 头 至 尾 操作 一 遍 ， 不 知道 您 的 感想 如 何 ; 


一 一 “被 眼花 纺 乱 的 Git 魔 法 彻底 搞 糊涂 了 ? ” 


一 一 “Git 为 什么 这 么 折 麻 人 ， 修 改 的 文件 直接 提交 不 就 完了 吗 ? ” 


一 一 看 不 出 Git 文 么 做 有 什么 好 处 ? ” 


上 上面 的 实践 过 程 有 意 无 意 地 透漏 了 “和 暂 存 区 ”的 概念 。 为 了 避免 用 
户 被 新 概念 吓 坏 ， 在 暂 存 区 出 现 的 地 方 又 同时 使 用 了 “提交 任务 "这 一 
更 易 理解 的 概念 ， 但 是 暂 存 区 〈 称 为 stage 或 index) 才 是 其 真正 的 名 
称 。 我 认为 Git 暂 存 区 的 设计 是 Git 最 成 功 的 设计 之 一 ， 但 也 是 最 难 理 
解 的 。 


在 版 本 库 .git 目 录 下 有 一 个 index 文 件 ， 下 面 针 对 这 个 文件 做 一 个 有 
趣 的 试验 。 要 说 明 的 是 : 这 个 试验 是 用 1.7.3 版 本 的 Git 进 行 的 ， 低 版 本 
的 Git 因 为 没有 和 针对 git status 命 令 进行 优化 设计 ， 需 要 运行 git diff 命 令 
才能 看 到 index 文 件 的 日 期 截 变化 ， 具 体操 作 步 骤 如 下 。 


(1) 首先 执行 git checkout 命 令 〈 后 面 会 介绍 此 命令 ) ， 撤 销 工作 
区 中 welcome.txt 文 件 尚未 提交 的 修改 。 


$git checkout--welcome.txt 
$git status-s# 执 行 git diff, 如果 git 版 本 号 小 于 1.7.3 


(2) 通过 状态 输出 可 以 看 到 工作 区 已 经 没有 改动 了 。 查 看 一 
下 .giUVindex 文 件 ， 注 意 该 文件 的 时 间 愉 为: 19:37:44。 


$1s--full-time.git/index 
-rw-r--r--1 jiangxin jiangxin 112 2010-11-29 
19:37:44.625246224+0800 .git/index 


(3) 再 次 执行 git status 命 令 ， 然 后 显示 .git/index 文 件 的 时 间 翟 
为 : 19:37:44， 与 上 面 的 一 样 。 


$git status-s# 执 行 git diff, 如果 git 版 本 号 小 于 1.7.3 

$1s--full-time.git/index 

-rw-r--r--1 jiangxin jiangxin 112 2010-11-29 
19:37:44.625246224+0800 .git/index 


(4) 现在 更 改 一 下 welcome.txt 的 时 间 惟 ， 但 是 不 改变 它 的 内 容 。 
然后 再 执行 git status 命 令 ， 碍 看 .giUyindex 文 件 的 时 间 惟 为 : 19:42:06 。 


$touch welcome.txt 

$git status-s# 执 行 git diff, 如 果 git 版 本 号 小 于 1.7.3 

$1s--full-time.git/index 

-rw-r--r--1 jiangxin jiangxin 112 2010-11-29 
19:42:06.980243216+0800 .git/index 


看 到 了 吗 ， 时 间 稚 改变 了 


这 个 试验 说 明 当 执行 git status 命 令 (或 者 git diff 命 令 ) 扫描 工作 区 
改动 的 时 候 ， 先 依据 .givindex 文 件 中 记录 的 (用 于 跟 踩 工 作 区 文件 
的 ) 时 间 礁 、 长 度 等 信息 判断 工作 区 文件 是 否 改变 ， 如 采 工 作 区 文件 
的 时 间 礁 改变 了 ， 说 明文 件 的 内 容 可 能 补 改 变 了 ， 需 要 打开 文件 ， 读 
取 文 件 内 容 ， 与 更 改 前 的 原始 文件 相 比 较 ， 判 断 文 件 内 容 是 否 补 更 
改 。 如 果 文 件 内 容 没有 改变 ， 则 将 该 文件 新 的 时 间 戳 记录 到 .giUindex 
文件 中 。 因 为 如 果 要 判断 文件 是 否 更 改 ， 使 用 时 间 崔 、 文 件 长 度 等 信 
轧 进 行 比较 要 比 通过 文件 内 容 比 较 要 快 得 多 ， 所 以 Git 这 样 的 实现 方式 
可 以 让 工作 区 状态 扫 朱 更 快速 地 执行 ， 这 也 是 Git 高 效 的 原因 之 一 。 


文件 .gitindex 实 际 上 就 是 一 个 包含 文件 索引 的 目录 树 ， 像 是 一 个 
虚拟 的 工作 区 。 在 这 个 虚拟 工作 区 的 目录 树 中 ， 记 录 了 文件 名 和 文件 
的 状态 信息 《时间 戳 和 文件 长 度 等 ) 。 文 件 的 内 容 并 没有 存储 在 其 
中 ， 而 是 保存 在 Git 对 象 库 .git/objects 目 录 中 ， 文 件 索 引 建 立 了 文件 和 
对 象 库 中 对 象 实 体 之 间 的 对 应 。 图 5-1 展 示 了 工作 区 、 版 本 库 中 的 暂 存 
区 和 版 本 库 之 间 的 关系 。 


5-1 工作 区 、 版 本 库 、 暂 存 区 原理 图 


从 图 5-1 中 可 以 看 到 部 分 Git 命 仿古 如 何 有 影响 工 作 区 和 暂 存 区 的 。 
这 些 命令 的 面纱 将 在 接 下 来 的 儿 个 章节 中 彻底 扬 开 ， 下 面 吏 对 这 些 命 
令 进行 位 要 说 明 : 


中 左 侧 为 工作 区 ， 右 侧 为 版 本 库 。 在 版 本 库 中 标记 为 index 的 区 
域 是 特 存 区 ， 标 记 为 master 的 是 master 分 文 所 代表 的 目 永 树 。 


中 可 以 看 出 ， 此 时 HEAD 实 际 是 指 辣 master 分 支 的 一 个 “游标 ””， 
所 以 图 示 的 命令 中 出 现 HEAD 的 地 方 可 以 用 master 来 替换 。 


中 的 objects 标 识 的 区 域 为 Git 的 对 象 库 ， 实 际 位 于 .git/objects 目 录 
下 ， 这 一 点 会 在 后 面 的 划 节 中 重点 介绍 。 


当 对 工作 区 修改 (或 新 增 ) 的 文件 执行 git add 命 令 时 ， 暂 存 区 的 
目录 树 将 被 更 新 ， 同 时 工作 区 修改 (或 新 增 ， 的 文件 内 容 会 被 写 入 到 
对 象 库 中 的 一 个 新 的 对 象 中 ， 而 该 对 象 的 ID 被 记录 在 暂 存 区 的 文件 索 
i 


当 执 行 提 交 操 作 (git commit) 时 ， 和 暂 存 区 的 目录 树 会 写 到 版 本 库 
(对 象 库 ) 中 ，master 分 支 会 做 相应 的 更 新 ， 即 master 最 新 指向 的 日 录 
树 就 是 提交 时 原 暂 存 区 的 目录 树 。 


当 执行 git reset HEAD 命 令 时 ， 暂 存 区 的 目录 树 会 被 重 写 ， 会 被 


受 影响 。 


master 分 文 指 向 的 目录 树 所 替换 ， 但 是 工作 区 不 
当 执 行 git rm--cached < 人 le 命令 时 ,会 直接 从 和 暂 存 区 删除 文件 ， 


工作 区 则 不 做 出 改变 。 
当 执 行 git checkout. 或 git checkout--<file> 命令 时 ， 会 用 暂 存 区 全 


部 的 文件 或 指定 的 文件 替换 工作 区 的 文件 。 这 个 操作 很 危险 ， 会 清除 
工作 区 中 未 添加 到 和 暂 存 区 的 改动 。 


全 
研 


当 执 行 git checkout HEAD. 或 git checkout HEAD<file > 命令 时 ， 
用 HEAD 指 问 的 master 分 支 中 的 全 部 或 部 分 文件 蔡 换 和 暂 存 区 和 工作 区 中 


也 是 极 具 危险 性 的 ， 因 为 不 但 会 清除 工作 区 中 未 拓 


的 文 作 过 这 个 商学 
交 的 改动 ， 也 会 清除 暂 存 区 中 未 提交 的 改动 。 


5.3 ”Git Diff 魔 法 


本 章 的 实践 展示 了 具有 魔法 效果 的 命令 : git dif。 在 不 同 参 数 的 
作用 下 ，git dift 的 输出 并 不 相同 。 在 理解 了 Git 中 的 工作 区 、 暂 存 区 和 
版 本 库 〈 当 前 分 支 ) 的 最 新 版 本 分 别 是 三 个 不 同 的 目录 树 后 ， 就 非常 
好 理解 git diff 的 魔法 般 的 行为 了 。 


1. 工 作 区 、 午 存 区 和 版 本 库 的 目录 树 济 哆 


有 什么 办 法 能 够 像 查 看 工作 区 一 样 直观 地 查看 和 暂 存 区 及 HEAD 中 
的 目录 树 吗 ? 


对 于 HEAD (版 本 库 中 当前 提交 ) 指向 的 目录 树 ， 可 以 使 用 Git 故 


层 命令 ls-tree 来 查看 。 


$git Js-tree-1 HEAD 
100644 blob fd3co69c1de4f4bc9b15940f490aeb48852f3c42 25 
welcome.txt 


其 中 : 


使 用 -] 参 数 可 以 显示 文件 的 大 小 。 上 面 的 welcome.txt 的 大 小 为 25 字 


节 。 


输出 的 welcome.txt 文 件 条 目 从 左 至 右 ， 第 一 个 字段 是 文件 的 属性 
(rw-r--r--) ， 第 二 个 字段 说 明 是 Git 对 象 库 中 的 一 个 blob 对 象 ( 文 
件 ) ， 第 三 个 字段 则 是 该 文件 在 对 象 库 中 对 应 的 ID 一 一 一 个 40 位 的 
SHA1 哈 希 值 格式 的 ID (这 个 会 在 后 面 介绍 ) ， 第 四 个 字段 是 文件 大 
小 ， 第 五 个 字段 是 文件 名 。 


在 浏览 暂 存 区 中 的 目录 树 之 前 ， 首 先 清除 工作 区 当前 的 改动 。 通 
过 git clean-fd 命 令 清 除 当前 工作 区 中 没有 加 入 版 本 库 的 文件 和 目录 
( 非 跟 踪 文 件 和 目录 ) ， 然 后 执行 git checkout. 命 令 ， 用 和 暂 存 区 内 容 刷 
新 工作 区 。 


$cd/path/to/my/workspace/demo 
$git clean-fd 
$git checkout. 


然后 开始 在 工作 区 中 做 出 一 些 修 改 〈 修 改 welcome.txt， 再 增加 一 
个 子 目 录 和 文件 ， 并 添加 到 暂 存 区 ， 最 后 再 对 工作 区 做 出 修改 。 


$echo "Bye-Bye."> >welcome.txt 
$mkdir-p a/b/c 

$echo "Hello.">a/b/c/hello.txt 
$git add. 

$echo "Bye-Bye."> >a/b/c/hello.txt 
$git status-s 

AM a/b/c/hello.txt 

M welcome.txt 


上 面 的 命令 运行 完毕 后 ， 通 过 精简 的 状态 输出 可 以 看 出 ， 工 作 
区 、 暂 存 区 和 版 本 库 当 前 分 支 的 最 新 版 本 (HEAD) 各 不 相同 。 先 来 
看 看 工作 区 中 文件 的 大 小 : 


$find.-path./.git-prune-o-type f-printf "%-20p\t%s\n" 
/welcome.txt 34 
./a/b/c/hello.txt 16 


要 显示 暂 存 区 的 目 孙 树 ， 可 以 使 用 git ls-files 命 令 。 


$git ls-files-s 

100644 18832d35117ef2f013c4009f5b2128dfaeff354f 0 
a/b/c/hello.txt 

100644 51dbfd25a804c30e9d8dc441740452534de8264b 0 welcome.txt 


注意 ， 这 个 输出 与 之 前 使 用 git ls-tree 命 令 的 输出 不 一 样 ， 其 中 第 
三 个 字段 不 是 文件 大 小 而 是 暂 存 区 编号 。 如 果 想 针对 和 暂 存 区 的 目录 树 
使 用 git ls-tree 命 令 ， 需 要 先 将 暂 存 区 的 目录 树 写 入 Git 对 象 库 (用 git 
write-tree 命 令 ) ， 然 后 针对 该 日 录 树 执行 git ls-tree 命 令 


$git write-tree 

9431f4a3f3e1504e03659406faa9529f83cd56f8 

$git ls-tree-1] 9431f4a 

040000 tree 53583ee687fbb2e913d18d508aefd512465b2092-a 

100644 blob 51dbfd25a804c30e9d8dc441740452534de8264b 34 
welcome.txt 


从 上 面 的 命令 中 可 以 看 出 : 


到 处 都 是 40 位 的 SHA1 哈 希 值 格式 的 ID， 可 以 用 于 指 代 文件 内 容 
(blob) 、 目 录 树 (tree) 和 提交 。 但 什么 是 SHA1 哈 希 值 ID， 作 用 是 
什么 ， 这 些 疑 问 和 暂时 搁置 ， 下 一 章 再 解答 。 


命令 git write-tree 的 输出 就 是 写 入 Git 对 象 库 中 的 Tree ID， 这 个 ID 
将 作为 下 一 条 命令 的 输入 。 


在 git ls-tree 命 令 中 ， 没 有 把 40 位 的 ID 写 全 ， 而 是 使 用 了 前 几 位 ， 
实际 上 只 要 不 与 其 他 对 象 的 ID 剖 突 ， 残 可 以 随心 所 欲 地 使 用 缩写 ID 。 


可 以 看 到 git ls-tree 的 输出 显示 的 第 一 条 是 一 个 tree 对 象 ， 即 刚才 创 
建 的 一 级 目录 a 。 


如 条 想 要 递归 显示 目 孙 内 容 ， 则 使 用 -r 参 数 调用 。 使 用 参数 -t 可 以 
把 递归 过 程 中 遇 到 的 每 棵 树 都 显示 出 来 ， 而 不 只 是 显示 最 终 的 文件 。 
下 面 执行 递归 操作 显示 目录 树 的 内 容 : 


$git write-tree|xargs git ls-tree-l1-r-t 


040000 tree 53583ee687Efbb2e913dl18dG508aefd512465b2092 
040000 tree 514G729095b7bc203cft336723af710d41b84867Pb 
040000 tree dGeaec688e84302d4a0b98alb78a434be1lb22ca02 
100644 blob 18832d35117ef2f013c4009f5b2128dfaeff354f 
100644 blob Sidbfd25a804c30e9dBdc441740452534de8264b 


EE] 

ay 上 

aybyec 
a/b/c/hello.txt 
welcome .txt 


好 了 ， 现 在 工作 区 、 暂 存 区 和 HEAD 三 个 目录 树 的 内 容 各 不 相同 。 表 5-1 总 结 了 不 同文 


件 在 三 个 目录 树 中 的 文件 大 小 。 


表 5-1 文件 不 同 版 本 的 大 小 
文件 名 工作 区 | 暂 存 区 


welecnme 1x1 34 字 节 34 字 节 | 
aihicihello txt 16 字 节 7 季节 


2 ”Git diff 魔 法 


通过 使 用 不 同 的 参数 调用 git aiff 命令 ， 可 以 对 工作 区 、 暂 存 区 和 HEAD 中 的 内 容 


进行 两 两 比较 。 图 5-2 展示 了 不 同 的 git diff 命令 的 作用 范围 。 


图 5-2 ”git dif 命令 与 版 本 库 关 系 图 


通过 图 5-2 就 不 难 理解 下 面 代码 中 git diff 命令 的 不 同 输出 结果 了 ， 


(1) 工作 区 和 和 暂 存 区 比较 。 


s§ git diff 

diff -~--qit a/a/b/c/hello.txt bj/a/b/c/hello.txt 
index 188329d3. .e8577ea 100644 

"== a/la/b/c/heillo.txt 

+++ b/a/b/c/hello.txt 

BB -1 +1 .2 GEG 

Helilo. 

+BYe-BYe， 


(2) 暂 存 区 和 HEAD 比 较 。 


$git diff--cached 

diff--git a/a/b/c/hello.txt b/a/b/c/hello.txt 
new file mode 100644 

index 0000000. .18832d3 

---/dev/null 

+++b/a/b/c/hello.txt 

@0-0, 0+100 

+Hello. 

diff--git a/welcome.txt b/welcome.txt 
index fd3c069. .51dbfd2 100644 
---a/welcome.txt 

+++b/welcome .txt 

QQ-1, 2+1, 3@@ 

Hello. 

Nice to meet you. 

+Bye -Bye. 


(3) 工作 区 和 HEAD 比 较 。 


$git diff HEAD 

diff--git a/a/b/c/hello.txt b/a/b/c/hello.txt 
new file mode 100644 

index 0000000. .e8577ea 

---/dev/null 

+++b/a/b/c/hello.txt 

Q@Q@-0,0+1,2@@ 

+Hello. 

+Bye -Bye. 

diff--git a/welcome.txt b/welcome.txt 
index fd3c069..51idbfd2 100644 
---A/welcome.txt 

+++b/welcome. txt 

QQ-1, 2+1, 3@@ 

Hello. 

Nice to meet you. 

+Bye -Bye. 


5.4 不 要 使 用 git commit-a 


实际 上 ，Git 的 提交 命令 (git commit) 可 以 带 上 -a 参数 ， 对 本 地 所 
有 变更 的 文件 执行 提交 操作 ， 包 括 对 本 地 修改 的 文件 和 删除 的 文件 ， 
但 不 包括 未 被 版 本 库 跟踪 的 文件 。 


这 个 命令 的 确 可 以 简化 一 些 操 作 ， 减 少 用 git add 命 令 标识 变更 文 
件 的 步 又， 但 是 如 条 习惯 了 使 用 这 个 “ 偷 籁 "的 提交 命令 ， 束 会 丢掉 Git 
和 暂 存 区 带 给 用 户 的 最 大 好 处 ， 对 提交 内 容 进 行 控制 的 能 


有 的 用 户 甚 至 通过 别名 设置 功能 将 ci 设置 为 git commit-a， 这 是 更 
不 可 取 的 行为 ， 应 严格 禁止 。 本 书 很 少 会 使 用 git commit-a 命 令 。 


5.5 ”搁置 问题 ， 暂 存 状 态 


查看 一 下 当前 工作 区 的 状态 : 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..." to unstage) 
# 


#new file:a/b/c/hello.txt 
#modified:welcome.txt 


# 

#Changes not staged for commit: 

#(USe "git add<file>..."to update what will be committed) 

#(USe "git checkout--<file>..."to discard changes in working 
directory ) 


#modified:a/b/c/hello.txt 
# 


在 状态 输出 中 ，Git 体 贴 地 告诉 了 用 户 如 何 将 加 入 和 暂 存 区 的 文件 从 
暂 存 区 撤 出 以 便 让 和 暂 存 区 和 HEAD 一 致 (这 样 提交 就 不 会 发 生 ) 。 还 
告诉 用 户 ， 对 于 暂 存 区 更 新 后 在 工作 区 所 做 的 再 一 次 修改 有 两 个 选 
择 : 或 者 再 次 添加 到 暂 存 区 ， 或 者 取消 工作 区 新 做 出 的 改动 。 但 是 现 
在 理解 涉及 的 命令 还 有 些 难 度 ， 一 个 是 git reset， 一 个 是 git checkout 。 
需要 先 理解 什么 是 HEAD， 什 么 是 master 分 文 ， 以 及 Git 对 象 存 储 的 实 
现 机 制 等 问题 ， 这 样 才 可 以 更 好 地 操作 和 暂 存 区 。 


为 此 ， 我 做 出 一 个 非常 艰难 的 决定 : 束 是 保存 当前 的 工作 进度 ， 
在 研究 了 HEAD 和 master 分 支 的 机 制 之 后 ， 继 续 对 和 暂 存 区 的 探索 。 命 令 
git stash 束 是 用 于 保存 当前 工作 进度 的 。 


$git stash 

Saved working directory and index state WIP on master:e695606 
which version 

checked in? 

HEAD is now at e695606 which version checked in? 


运行 


完 git stash 之 后 ， 再 查看 工作 区 状态 ,会 看 见 工 作 区 尚未 提交 
的 改动 (包括 暂 存 区 的 改动 ) 全 都 不 见 了 。 


$git status 
#0n branch master 
nothing to commit(working directory clean) 


"TH be back。" (我 会 再 回来 的 。) 一 一 施 瓦 玉 格 ，《 终 结 者 》， 
1984° 


第 6 章 ”Git 对 象 


我 们 在 上 一 章 学 习 了 Git 的 一 个 最 重要 的 概念 : 暂 存 区 。 暂 存 区 是 
一 个 介 于 工作 区 和 版 本 库 的 中 间 状 态 ， 当 执行 提交 时 ， 实 际 上 是 将 暂 
存 区 的 内 容 提 交 到 版 本 库 中 ， 而 且 Git 的 很 多 命令 都 会 涉及 暂 存 区 的 概 
念 ， 例 如 git diff 命 令 。 


上 一 章 也 留 下 了 很 多 疑惑 ， 例 如 什么 是 HEAD? 什么 是 master? 为 
什么 它们 二 者 (在 上 一 章 ) 可 以 相互 奉 换 使 用 ?为 什么 Git 中 的 很 多 对 
象 (如 提交 、 树 、 文 件 内 容 等 ) 都 用 40 位 的 SHA1 哈 希 值 来 表示 ? 本 章 
将 会 揭 开 这 些 奥秘 ， 并 且 还 会 画 出 一 个 更 为 精确 的 版 本 库 结 构图 。 


6.1 Git 对 象 库 探秘 


前 面 刻 意 回避 了 对 提交 ID 的 说 明 ， 现 在 是 时 候 来 扬 开 由 40 位 十 六 
进 制 数字 组 成 的 "魔幻 数字 ”的 奥秘 了 。 


过 查看 日 志 的 详尽 输出 ， 我 们 会 惊讶 地 看 到 非常 多 的 “魔幻 数 
字 ”， 这 些 “ 魔 幻 数字 ”实际 上 是 SHA1 哈 希 值 。 


$git 1og-1--pretty=raw 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b1i0d8bccalied1ibf84ca80340fdefee6 
author Jiang Xin<jiangxin@ossxp.com>1291022581+0800 


committer Jiang Xin<jiangxin@ossxp.com>1291022581+0800 
which version checked in? 


一 个 提交 中 居然 包含 了 三 个 SHA1 哈 希 值 表示 的 对 象 ID: 


commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86: 这 是 本 次 提 


区 的 唯一 标识 2 


[0 
站 
Dy 
由 


tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9: 这 
所 对 应 的 目 孙 树 。 


parent a0c641e92b10d8bccaled1bf84ca80340fdefee6: 这 是 本 地 提 


区 的 尺 可 六 上 二 人 提交 让 注 


研究 Git 对 象 ID 的 一 个 重量 级 武 帮 就 是 git cat-file 命 令 。 用 下 面 的 命 
令 可 以 查看 一 下 这 三 个 ID 的 类 型 。 

$git cat-file-t e695606 

commit 

$git cat-file-t f58d 

tree 

$git cat-file-t a0c6 

commit 

在 引用 对 象 ID 的 时 候 ， 没 有 必要 把 整个 的 40 位 ID 写 全 ， 只 要 从 头 
开始 的 几 位 不 冲突 即 可 。 下 面 再 用 git cat-file 命 令 查看 一 下 这 几 个 对 象 
的 内 容 。 


commit 寺 象 e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


$git cat-file-p e695606 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin<jiangxin@ossxp.com>1291022581+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291022581+0800 
which version checked in? 


tree 对 和 象 f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 


$git cat-file-p f58da9a 
100644 blob fd3co69c1de4f4bc9b15940f490aeb48852f3c42 welcome.txt 


commit 寺 象 a0c641e92b10d8bccaled1bf84ca80340fdefee6 


$git cat-file-p agoc641e 

tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 

parent 9e8a761ff9dd343a1380032884f488a2422c495a 

author Jiang Xin<jiangxin@ossxp.com>1290999606+0800 
committer Jiang Xin<jiangxin@ossxp.com>1290999606+0800 
who does commit? 


在 上 面 的 目录 树 (tree) 对 象 中 看 到 了 一 个 新 类 型 的 对 象 : blob 对 
象 ， 这 个 对 象 保 存 着 文件 welcome.txt 的 内 容 ， 我 们 用 git cat-file 人 研究 一 
下 


oO 


该 对 象 的 类 型 为 blob 。 


$git cat-file-t fd3c069c1de4f4bc9b15940f490aeb48852f3c42 
blob 


该 对 象 的 内 容 就 是 welcome.txt 文 件 的 内 容 。 


$git cat-file-p fd3co069c1de4f4bc9b15940f490aeb48852f3c42 
Hello. 
Nice to meet you. 


这 些 对 象 保存 在 哪里 ? 当然 是 Git 库 中 的 objects 目 录 下 了 (ID 的 前 
2 位 作为 目录 名 ， 后 38 位 作为 文件 名 ) 。 用 下 面 的 命令 可 以 看 到 这 些 对 
象 在 对 和 象 库 中 的 实际 位 置 。 


$for id in e695606 f58da9a ao0c641e fd3c069; do\ 
ls.git/objects/${id:0:2}/${id:2}*; done 
.git/objects/e6/95606fc5e31b2ff9038a48a3d363f4c21a3d86 
.git/objects/f5/8da9a820e3fd9d84ab2ca2f1b467ac265038f9 
.git/objects/a0/c641e92b1i0d8bccalied1ibf84ca80340fdefee6 


.qit/obiects/fd/3c069c1lde4f4bc9biS5940f490aeb48852f3c42 


图 6-1 更 加 清楚 地 显示 了 Git 对 象 库 中 各 个 对 象 之 间 的 关系 。 


| COMMIT _ tree 
oId e695666 Id: f58da9a Id: fd3ce69 


Tree “586da9a 
"Parent a8c641e 人 内 容 .. ， 
"Author Jiang Xin Fn welcome txt 


EY 
Id abgc641e 
Tree 196d846 
"Parent 9e8a761 
Author Jiang Xin 


图 6-1 Git 版 本 库 对 象 关 系 医 


通过 提交 (Commit) 对 象 之 间 的 相互 关联 ， 可 以 很 容易 地 识 列 出 一 条 跟踪 链 ， 这 条 
跟踪 链 可 以 在 运行 git log 命令 时 通过 --graph 人 参数 看 到 。 下 面 的 命令 还 使 用 了 -- 
pretty=raw 参数， 以 便 显 示 每 个 提交 对 象 的 parent 属性 。 
git log -~-pretty=raw ~~Graph e695606 
Cammit esgsa0o6fosea31lb2ff9038adBa3d3saf4c21a3d86 
tree ft58da9as20e3fq99584ab2ca2f1b457ac265033f9 
parent a0c641le9zbiodgbccaledlbf84caB80340fdefees 


author Jiang Xin <jiangxinecssxp .com> 1291022581 +0800 


committer Jiang Xin <jiangxin®@ossxp.com> 1291022581 +0800 
which version checked in? 

commit an0c6sd1e92b10a8bcecaledlpfB4cas0340fdefees 

tree 190d840dq3d8fa3l9bdec6b8112pb09357be7ee759 

parent 9e8a761fft9dd343a1380032884f488a2422C495a 

author Jiang Xin <jiangxinecssxp .com> 1290999606 +0800 

committer Jiang Xin <jiangxinocossxp .com> 1290999606 +0800 
who does commit? 


S 
这 
全 
二 


commit 9ega7éliff9dd343a1380032884f488a2422c495a 

tree i190d840da3d8fa3i9bdecébail2b0957beTee769 

author Jiang Xin <jiangxin@ossxp.com> 1290919706 +0800 
committer Jiang Xin <ijiangxinBossxp.com> 1290919706 +0800 


initialized. 


最 后 一 个 提交 没有 parent 属性 ， 所 以 跟踪 链 到 此 终结 ， 这 实际 上 就 是 提交 的 起 点 。 


现在 来 看 看 HEAD 和 master 的 奥秘 吧 。 


因为 在 上 一 章 的 最 后 执行 了 git stash 命 令 来 将 工作 区 和 和 暂 存 区 的 改 
动 全 部 封存 起 来 ， 所 以 执行 下 面 的 命令 会 看 到 工作 区 和 和 暂 存 区 中 没有 
改动 。 


$git status-s-b 
##master 


说 明 上 面 在 显示 工作 区 状态 时 ， 除 了 使 用 了 -s 参 数 以 显示 精简 
输出 外 ， 还 使 用 了 -b 参 数 ， 以 便 能 够 同时 显示 出 当前 工作 分 文 的 名 


称 ， 这 个 -pb 参数 是 在 Git 1.7.2 以 后 加 入 的 新 参数 。 


下 面 的 git branch 是 分 支管 理 的 主要 命令 ， 也 可 以 显示 当前 的 工作 
分 支 。 


$git branch 
*master 


在 master 分 文 名 称 前 的 星 号 表明 这 个 分 文 是 当前 工作 分 文 。 至 于 
为 什么 没有 其 他 分 文 ， 以 及 什么 叫 分 文 ， 会 在 本 书后 面 的 章节 中 讲 
解 。 


现在 连续 执行 下 面 的 三 个 命令 会 看 到 相同 的 输出 : 


$git 1og-1 HEAD 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Mon Nov 29 17:23:01 2010+0800 

which version checked in? 

$git 1og-1 master 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Mon Nov 29 17:23:01 2010+0800 

which version checked in? 

$git log-1 refs/heads/master 

commit e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Mon Nov 29 17:23:01 2010+0800 

which version checked in? 


也 就 是 说 ， 在 当前 版 本 库 中 ，HEAD、master 和 refs/heads/master 具 
有 相同 的 指向 。 现 在 到 版 本 库 (.git 目 录 ) 中 一 探 它们 的 究竟 。 


$find.git-name HEAD-o-name master 
.git/HEAD 

.git/l1ogs/HEAD 
.git/logs/refs/heads/master 
.git/refs/heads/master 


找到 了 4 个 文件 ， 其 中 在 .givlogs 目 录 下 的 文件 稍 后 再 予以 讨论 ， 
现在 把 目光 锁定 在 .giWHEAD 和 .git/refs/heads/master 上 。 


显示 一 下 .giWHEAD 的 内 容 : 


$§ cat .git/HEAD 
ref: refs/heads/master 


把 HEAD 的 内 容 翻 译 过 来 就 是 :“ 指 向 一 个 引用 ; refs/heads/master”"。 这 个 引用 在 哪 
里 ? 当然 是 文件 ,git/refs/heads/master 了 。 

看 看 文件 .git/refs/heads/master 的 内 容 。 

$ cat .git/refs/heads/master 

e695606fc5e31b2Ef9038a#6a3d363E4Cc21a3dBE 

显示 的 e695606... 所 指 为 何 物 ? 可 用 git cat-file 命令 查看 。 

(1) 显示 SHA1 哈 希 值 指 代 的 数据 类 型 ， 

$ git cat-file -~t e695606 

cammit 

(2) 显示 该 提交 的 内 容 ， 


8 git cat-file -~-P e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
tree fS8da9a820e3fd9d84ab2ca2f1b467ac26S5038f9 

parent a0c641e92bl0d8bccaledibf84ca80340fdefeet 

author Jiang Xin <ijiangxin@ossxp.com> 1291022581 +0800 
committer Jiang Xin <jiangxinBossxp.com> 1291022581 +0800 


which version checked in? 


原来 分 支 master 指向 的 是 一 个 提交 ID 最 新 提交 )。 这 样 的 分 支 实现 是 多 么 的 巧妙 啊 : 既 
然 可 以 从 任何 提交 开始 建立 一 条 历史 跟踪 链 ， 用 一 个 文件 指向 这 个 链条 的 最 新 提交 ， 那 么 这 个 
文件 就 可 以 用 于 追踪 整个 提交 历 虫 了 。 这 个 文件 就 是 .git/refs/heads/master 文件 。 

下 面 看 一 个 更 接近 于 真实 的 版 本 库 结构 图 ， 如 图 6-2 所 示 。 


tree 
"id e695696 TITd: fsadaga 


Tree ”了 56da95 
"parent 3955418 
Author Jiang Xin DD) welcome txt 


COMMIT _ | 
id agc64le 
Tree 190d840 
Pparent 9e5a7651 
AUthor Jiang Xain 


图 6-2 Git 版 本 库 结构 图 


目录 .git/refs 是 保存 3 引用 的 命名 空间 ， 其 中 .git/refs/heads 目 录 下 的 
引用 又 称 为 分 文 。 对 于 分 文 ， 既 可 以 使 用 正规 的 长 格式 的 表示 法 ， 如 
refs/heads/master， 也 可 以 去 掉 前 面 的 两 级 目录 用 master 来 表示 。Git 有 
一 个 底层 命令 git rev-parse 可 以 用 于 显示 引用 对 应 的 提交 ID。 


$git rev-parse master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
$git rev-parse refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
$git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


可 以 看 出 它们 都 指 问 同一 个 对 象 。 为 什么 这 个 对 象 是 40 位 ， 而 不 
是 更 少 或 更 多 ? 这 些 ID 是 如 何 生 成 的 呢 ? 


6.2 思考 : SHA1 哈 硕 值 到 搬 是 什么 ， 征 如 何 生 
成 的 


哈 希 (hash) 叫 是 一 种 数据 摘要 算法 〈 或 称 散 列 算法 ) ， 是 信息 
安全 领域 中 重要 的 理论 基石 。 该 算法 将 任意 长 度 的 输入 经 过 散 列 运 外 
转换 为 固定 长 度 的 输出 。 固 定 长 度 的 输出 可 以 称 为 对 应 输入 内 容 的 数 
字 摘 要 或 哈 希 值 。 例 如 SHA1 摘 要 算法 可 以 处 理 从 零 到 两 百 多 万 TB 
的 输入 数据 ， 输 出 为 固定 的 160 比 特 的 数字 摘要 。 即 使 两 个 不 同 内 容 的 
输入 数据 量 非常 大 、 差 异 非常 小 ， 两 者 的 哈 硕 值 也 会 显著 不 同 。 比 较 
著名 的 摘要 算法 有 : MD5 和 SHA1。Linux 下 shalsum 命 令 可 以 用 于 生成 
摘要 。 


$printf Git|shaisum 
5819778898df55e3a762f0c5728b457970d72cae- 


可 以 看 出 字符 串 Git 的 SHA1 哈 希 值 由 40 个 十 六 进 制 的 数字 组 成 。 
那么 能 不 能 找 出 另外 一 个 字符 串 使 其 SHA1 哈 希 值 和 上 面 的 哈 希 值 一 样 
呢 ? 下 面 来 看 看 难度 有 多 大 。 


每 个 十 六 进 制 的 数字 相当 于 一 个 4 位 的 二 进 制 数字 ， 因 此 40 位 的 
SHA1 哈 希 值 的 输出 实际 为 160 比 特 。 拿 双色 球 博彩 打 一 个 比喻 ， 要 想 
制造 相同 的 SHA1 哈 希 值 就 相当 于 要 选 出 32 个 “红色 球 "， 每 个 红 球 有 1 


到 32 个 (5 位 的 二 进 制 数字 ) 选择 ， 不 但 红 球 之 间 可 以 重复 ， 而 且 选 出 
红 球 的 顺序 必须 一 致 。 相 比 “ 双 色 球 博彩 ”总 共 只 须 选 出 6 颗 红 球 (1 到 
33) 外 加 1 个 篮球 (1 到 16) ，SHA1“ 中 奖 ” 的 难度 差不多 相当 于 要 连续 
购买 七 期 中 由 “双色 球 * 并 且 每 一 期 都 必需 中 一 等 奖 。 当 然 由 于 算法 上 
的 问题 ， 制 造 冲 突 (相同 数字 摘要 ) 的 几率 没有 那么 小 中 ,但 是 已 经 
足够 小 了 ， 能 够 满足 Git 对 不 同 的 对 象 进行 区 分 和 标识 了 。 即 使 有 一 天 
像 发 现 了 类 似 MD5 摘 要 算法 的 冲突 那样 ， 发 现 了 SHA1 算 法 存在 人 为 
制造 冲突 的 可 能 ， 那 么 Git 可 以 使 用 更 为 安全 的 SHA-256 或 SHA-512 的 
摘要 算法 。 


可 是 Git 中 的 各 种 对 象 ， 提交 (commit) 、 文 件 内 容 (blob) 、 目 
录 树 (tree) 等 中 ， 其 对 应 的 SHA1 哈 希 值 是 如 何 生 成 的 呢 ? 下 面 就 来 
展示 全 下 


先 看 一 看 提交 的 SHA1 哈 希 值 生成 方法 。 


(1) 看 看 HEAD 对 应 的 提交 的 内 容 ， 使 用 git cat-file 命 令 。 


$git cat-file commit HEAD 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent ao0c641e92b10d8bccaled1bf84ca80340fdefee6 

author Jiang Xin<JjiangxinQ@ossxp.com>1291022581+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291022581+0800 
which version checked in? 


$git cat-file commit HEAD|wc-c 
234 


(3) 在 提交 信息 的 前 面 加 上 内 容 commit 234<nul> (<null> 为 


空 字符 ) ， 然 后 执行 SHA1 哈 希 算法 。 


$(printf "commit 234\000"; git cat-file commit HEAD)|shaisum 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86- 


(4) 上 面 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 


$git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


下 面 来 看 一 看 文件 内 容 的 SHA1 哈 布 值 生成 方法 。 


(1) 看 看 版 本 库 中 welcome.txt 的 内 容 ， 使 用 git cat-file 命 令 。 


$git cat-file blob HEAD:welcome.txt 
Hello. 
Nice to meet you. 


(2) 文件 总 共 包含 25 字 节 的 内 容 。 


$git cat-file blob HEAD:welcome.txt|wc-c 
25 


(3) 在 文件 内 容 的 前 面 加 上 blob 25<null> 的 内 容 ， 然 后 执行 
SHA1 哈 希 算法 。 


$(printf "blob 25\000";git cat-file blob 
HEAD:welcome.txt)|shailsum 
fd3c069c1de4f4bc9b15940f490aeb48852f3c42- 


(4) 上 面 的 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 


$git rev-parse HEAD:weJcome .txt 
fd3c069c1de4f4bc9b15940f490aeb48852f3c42 


最 后 再 来 看 看 树 的 SHA1 哈 希 值 的 形成 方法 。 
(1) HEAD 对 应 的 树 的 内 容 共 包含 39 个 字 节 。 


$git cat-file tree HEAD^{tree}|wc-c 
39 


(2) 在 树 的 内 容 的 前 面 加 上 tree 39<null> 的 内 容 ， 然 后 执行 
SHA1 哈 希 算 法 。 


$(printf "tree 39\000";git cat-file tree HEAD^{tree})|shaisum 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9- 


(3) 上 面 的 命令 得 到 的 哈 希 值 和 用 git rev-parse 看 到 的 是 一 样 的 。 


$git rev-parse HEAD^{tree} 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 


后 面 在 学 习 里 程 碑 (Tag) 的 时 候 会 看 到 ，Tag 对 象 ( 轻 量 级 Tag 除 
外 ) 也 是 采用 类 似 的 方法 在 对 象 库 中 存储 的 。 


[1| http://en.wikipedia.org/wiki/Cryptographic_hash_ function#cite_ref-13 
[2] 2% -1 比特 ， 相 当 于 209 万 TB。1TB 相 当 于 1024GB 。 

[3] 160 比 特 分 成 32 组 ， 每 组 5 个 比特 。 

[4] 160=24s6.6 

[5] 相当 于 连续 购买 两 期 双色 球 彩 票 且 都 中 一 等 奖 。 

[6] 还 有 tag 对 象 ， 参 见 第 3 篇 第 17.2.2 节 。 


6.3 思考: 为 什么 不 用 顺序 的 数 子 来 表示 提交 


到 目前 为 止 所 进行 的 提交 都 是 顺序 提交 ， 这 可 能 会 让 您 产生 这 人 么 
一 个 想法 ， 为 什么 Git 的 提交 不 依据 提交 顺序 对 提交 进行 编号 呢 ? 可 以 
把 第 一 次 提交 定义 为 提交 1， 依 次 迎 增 。 尤 其 是 对 于 拥有 像 Subversion 
等 集中 式 版 本 控制 系统 使 用 经 验 的 用 户 而 言 ， 更 会 有 这 样 的 体会 和 想 
法 。 


集中 式 版 本 控制 系统 因为 只 有 一 个 集中 式 的 版 本 库 ， 所 以 可 以 很 
容易 地 实现 依次 递增 的 全 局 唯一 的 提交 号 ， 像 Subversion 束 是 如 此 。 
Git 作 为 分 布 式 版 本 控制 系统 ， 开 发 可 以 是 非 线性 的 ， 每 个 人 都 可 以 通 
过 克隆 版 本 库 的 方式 工作 在 不 同 的 本 地 版 本 库 当 中 ， 在 本 地 做 的 提交 
可 以 通过 版 本 库 之 间 的 交互 (推送 和 拉 回 操作 ) 而 互相 分 发 ， 如 果 提 
区 采用 本 地 唯一 的 数字 编号 ， 在 提交 分 发 的 时 候 会 不 可 避免 地 造成 冲 
突 。 这 了 吏 要 求 提 区 的 编号 不 能 仅仅 是 本 地 局 部 有 效 ， 而 是 要 "全球 唯 
一 ”。Git 的 提交 通过 SHA1 哈 希 值 作为 提交 ID， 的 确 做 到 了 “全球 唯 


Mercurial (Hg) 是 另外 一 个 著名 的 分 布 式 版 本 控制 系统 ， 它 的 提 
交 ID 非 第 有 趣 ， 同 时 使 用 了 顺序 的 数字 编号 和 “全 球 唯一 "的 SHA1 哈 布 
值 。 但 实际 上 顺序 的 数字 编号 只 十 本 地 有 效 ， 对 于 克隆 版 本 库 来 说 没 


有 意义 ， 只 有 SHA1 哈 希 值 才 是 通用 的 编号 。 下 面 来 看 一 个 Hg 的 示 
例 : 


$hg lo0g--limit 2 

修改 集 :3009:2f1la3a7e8eb0 

标签 :tip 

户 :Daniel Neuhuser <dasdasich@gmail.com> 
日 期 :Wed Dec 01 23:13:31 2010+0100 

摘 安 :"Fixed"the CombinedHTMLDiff test 

路 改 集 ;3008:2fd3302ca7e5 

j 户 :Daniel Neuhuser <dasdasich@gmail.com> 
日 期 :Wed Dec 01 22:54:54 2010+0100 
摘 安 :#559 Add 'htm]_permalink_text' confval 


Hg 的 设计 使 得 在 本 地 使 用 版 本 库 更 为 方便 ， 但 是 要 在 Git 中 做 类 似 
实现 却 很 难 ， 这 是 因为 Git 相 比 Hg 拥 有 真正 的 分 支管 理 功能 。 在 Git 中 
会 存在 当前 分 支 中 看 不 到 的 其 他 分 支 的 提交 ， 如 何 管 理 提 交 编 号 十 分 
复杂 。 


幸好 Git 提 供 了 很 多 方法 可 以 方便 地 访问 Git 库 中 的 对 象 : 


采用 部 分 的 SHA1 哈 希 值 。 不 必 把 40 位 的 哈 希 值 写 全 ， 只 采用 开头 
的 部 分 (4 位 以 上 ) ， 只 要 不 与 现 有 的 其 他 哈 硕 值 冲突 即 可 。 


使 用 master 代 表 分 支 master 中 最 新 的 提交 ， 也 可 以 使 用 全 称 


refs/heads/master 或 heads/master 。 


使 用 HEAD 代 表 版 本 库 中 最 近 的 一 次 提交 。 


符号 ^ 可 以 用 于 指 代 父 提交 。 例 如 : 


OHEAD^ 代 表 版 本 库 中 的 上 一 次 提交 ， 即 最 近 一 次 提交 的 父 所 


入 | 
4 
O 


OHEADAA 则 代表 HEADA^ 的 父 提 交 。 


对 于 一 个 提交 有 多 个 父 提交 ， 可 以 在 符号 ^ 后 面 用 数字 表示 是 第 几 


个 父 提交 。 例 如 : 


Oa573106^2 的 含义 是 提交 a573106 的 多 个 父 提交 中 的 第 二 个 父 提 


t 


OHEADA^1 相 当 于 HEAD^， 含 义 是 HEAD 的 多 个 父 提交 中 的 第 一 
个 父 提 交 。 


OHEADAA2 的 含义 是 HEADA (HEAD 父 提交 ) 的 多 个 父 提交 中 的 


全 二 一 人 人 入 


第 二 个 父 提交 。 
符号 一 <n>> 也 可 以 用 于 指 代 祖先 提交 。 例 如 : 
a573106~5 即 相当 于 a573106AAAAA。 
是 交 所 对 应 的 树 对 象 ， 可 以 用 类 似 如 下 的 语法 访问 : 


a573106^{tree} 


某 一 次 提交 对 应 的 文件 对 象 ， 可 以 用 如 下 的 语法 访问 : 


a573106:path/to/file 


暂 存 区 中 的 文件 对 象 ， 可 以 用 如 下 的 语法 访问 : 


:path/to/file 


您 可 以 使 用 git rev-parse 命 令 在 本 地 版 本 库 中 练习 一 下 : 


$git rev-parse HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 

$git cat-file-p e695 

tree f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

parent a0c641e92b10d8bcca1led1bf84ca80340fdefee6 

author Jiang Xin<]jiangxin@ossxp.com>1291022581+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291022581+0800 
which version checked in? 

$git cat-file-p e695^ 

tree 190d840dd3d8fa319bdec6b8112b0957be7ee769 

parent 9e8a761ff9dd343a1380032884f488a2422c495a 

author Jiang Xin<jiangxin@ossxp.com>1290999606+0800 
committer Jiang Xin<jiangxin@ossxp.com>1290999606+0800 
who does commit? 

$git rev-parse e695^{tree} 
f58da9a820e3fd9d84ab2ca2f1b467ac265038f9 

$git rev-parse e695^^{tree} 
190d840dd3d8fa319bdec6b8112b0957be7ee769 


在 本 篇 的 第 11.4.1 小 竹中， 还 会 讲解 更 多 访问 Git 对 象 的 技巧 ， 例 
如 使 用 tag 和 日 期 来 访问 版 本 库 对 象 。 


第 7 章 ”Git 重 置 


上 一 章 讲 解 了 版 本 库 中 对 象 的 存储 方式 ， 以 及 分 文 master 的 实 
现 。 即 master 分 支 在 版 本 库 的 引用 目录 (.gitrefs) 中 体现 为 一 个 引用 
文件 .git/refs/heads/master， 其 内 容 就 是 分 支 中 最 新 提交 的 提交 ID 。 


$cat .git/refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


上 一 章 还 通过 对 提交 本 身 数据 结构 的 分 析 看 到 ， 提 交 可 以 通过 对 
父 提 交 的 关联 实现 对 提交 历史 的 追溯 。 注 意 ， 下 面 的 git log 命 令 中 使 
用 了 --oneline 参 数 ， 类 似 于 --pretty=oneline， 但 是 可 以 显示 更 短小 的 提 
交 ID。 参 数 --oneline 在 Git 1.6.3 及 以 后 的 版 本 中 才 有 ， 老 版 本 的 Git 可 以 


使 用 参数 --pretty=oneline--abbrev-commit 瑟 代 。 


$git 1og--graph--oneline 

*e695606 which version checked in? 
*aQc641e who does commit? 

*9e8a761 initialized. 


那么 ， 是 不 是 有 新 的 提交 发 生 的 时 候 ，master 分 文 对 应 的 引用 文 
件 中 的 内 容 就 会 改变 呢 ? master 分 文 对 应 的 引用 文件 中 的 内 容 可 以 人 
为 地 改变 吗 ? 本 草 就 来 探讨 如 何 用 git reset 命 令 改变 分 文 引 用 文件 的 内 
容 ， 即 实现 分 文 的 重 置 。 


7.1 分 文 游标 master 探 秘 


先 来 看 看 当 有 新 的 提交 发 生 的 时 候 ， 文 件 .gitv/refs/heads/master 的 
内 容 如 何 改变 。 首 先 在 工作 区 创建 一 个 新 文件 ， 寻 且 叫 作 new- 
commit.txt， 然 后 提交 到 版 本 库 中 。 


$touch new-commit.txt 

$git add new-commit ,txt 

$git commit-m "does master follow this new commit?" 
[master 4902dc3]does master follow this new commit? 
0 files changed,0 insertions(+),0 deletions(-) 
create mode 100644 new-commit.txt 


此 时 工作 目录 下 会 有 两 个 文件 ， 其 中 文件 new-commit.txt 是 新 增 


的 。 


$1s 
New-commit.txt welcome.txt 


来 看 看 master 分 文 指向 的 提交 1D 是否 改变 了 。 


可 以 看 出 在 版 本 库 引 用 空间 (.git/refs/ 目 录 ) 下 的 master 文 件 内 容 
的 确 改 变 了 ， 指 向 了 新 的 提交 。 


$cat .git/refs/heads/master 
4902dc375672fbf52a226e0354100b75d4fe31e3 


O 


再 用 git log 查 看 一 下 提交 日 志 ， 可 以 看 到 刚刚 完成 的 提交 


$git 1og--graph--oneline 

*4902dc3 does master follow this new commit? 
*e695606 which version checked in? 

*aQc641e who does commit? 

*9e8a761 initialized. 


引用 refs/heads/master 束 好 像 古 一 个 游标 ， 在 有 新 的 提交 发 生 的 时 
候 指 辐 了 新 的 提交 。 可 是 如 末 只 可 上 、 不 可 下 ， 束 不 能 称 为 “游标 ”。 
Git 提 供 了 git reset 命 令 ， 可 以 将 “游标 ” 指 癌 任意 一 个 存在 的 提交 ID。 下 
面 的 示例 就 尝试 人 为 地 更 改 游标 。 (注意 下 面 的 命令 中 使 用 了 --hard 参 
数 ， 会 破坏 工作 区 未 提交 的 改动 ， 慎 用 。) 


$git reset--hard HEADA^ 
HEAD is now at e695606 which version checked in? 


还 记得 上 一 章 介 绍 的 HEADA^ 代 表 了 HEAD 的 父 提 交 吗 ? 这 条 命令 
束 相 当 于 将 master 重 置 到 上 一 个 老 的 提交 上 。 我 们 来 看 一 下 master 文 件 
的 内 容 是 否 更 改 了 。 


$cat .git/refs/heads/master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


果然 ，master 分 支 的 引用 文件 的 指向 更 改 为 前 一 次 提交 的 ID 了 ， 
而 且 通 过 下 面 的 命令 可 以 看 出 新 添加 的 文件 new-commit.txt 也 丢失 了 。 


$1s 
welcome.txt 


重 置 命令 不 仅 可 以 重 置 到 前 一 次 提交 ， 而 且 还 可 以 直接 使 用 提 区 
ID 重 置 到 任何 一 次 提交 。 


(1) 通过 git log 查 询 到 最 早 的 提交 ID。 


$git 1og--graph--oneline 

*e695606 which version checked in? 
*aQc641e who does commit? 

*9e8a761 initialized. 


(2) 然后 重 置 到 最 早 的 一 次 提交 。 


$git reset--hard 9e8a761 
HEAD is now at 9e8a761 initialized. 


(3) 重 置 后 会 发 现 welcome.txt 也 回 退 到 原始 版 本 库 ， 曾 经 的 修改 
都 丢失 了 。 


$cat welcome.txt 
Hello. 


使 用 重 置 命令 很 危险 ， 会 彻底 地 丢弃 历史 。 那 么 ， 还 能 够 通过 浏 
览 提 区 历史 的 办 法 找到 丢弃 的 提交 ID， 再 使 用 重 置 命令 恢复 历史 吗 ? 
不 可 能 ! 因为 重 置 让 提交 历史 也 改变 了 ， 提 区 日 志 如 下 : 


$git 1og 

commit 9e8a761ff9dd343a1380032884f488a2422c495a 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Sun Nov 28 12:48:26 2010+0800 

initialized. 


7.2 ”用 reflog 挽 救 错 误 的 重 置 


如 有 果 没 有 记 下 重 置 前 master 分 文 指 同 的 提交 ID， 想 要 重 置 回 原来 
的 提交 似乎 是 一 件 麻 烦 的 事情 (去 对 象 库 中 一 个 一 个 地 找 ) 。 季 好 Git 
提供 了 一 个 挽救 机 制 ， 通 过 .gilogs 目 录 下 日 志文 件 记录 了 分 支 的 变 
更 。 默 认 非 裸 版 本 库 〈 带 有 工作 区 ) 都 提供 分 文 日 志 功 能 ， 这 是 因为 
市 有 工作 区 的 版 本 库 都 有 如 下 设置 : 


$git config core.logallrefupdates 
true 


查看 一 下 master 分 支 的 日 志文 件 .git/logs/refs/heads/master 中 的 内 
容 。 下 面 的 命令 显示 了 该 文件 的 最 后 儿 行 。 为 了 排版 的 需要 ， 还 将 输 
出 中 的 40 位 的 SHA1 提 交 ID 缩 短 。 


$tail-5.git/logs/refs/heads/master 

dca47ab ao0c641e Jiang Xin<,.,>1290999606+0800commit(amend ) :who 
does commit? 

ao0c641e e695606 Jiang Xin<,.,>1291022581+0800commit :which 
version checked in? 

e695606 4902dc3 Jiang Xin<.,...>1291435985+0800commit:does master 
follow... 

4902dc3 e695606 Jiang Xin<...~>1291436302+0800HEAD^:updating 
HEAD 

e695606 9e8a761 Jiang Xin<...>1291436382+08009e8a761:updating 
HEAD 


可 以 看 出 这 个 文件 记录 了 master 分 支 指向 的 变迁 ， 最 新 的 改变 追 
加 到 文件 的 末尾 ， 因 此 最 后 出 现 。 最 后 一 行 可 以 看 出 因为 执行 了 git 
reset--hard 命 令 ， 指 向 的 提交 ID 由 e695606 改 变 为 9e8a761。 


Git 提 供 了 一 个 git reflog 命 令 ， 对 这 个 文件 进行 操作 。 使 用 show 子 
命令 可 以 显示 此 文件 的 内 容 。 


$git reflog show master|head-5 

9e8a761 master@{0}:9e8a761:updating HEAD 

e695606 master@{1}:HEAD^:updating HEAD 

4902dc3 master@{2}:commit:does master follow this new commit? 
e695606 master@{3}:commit:which version checked in? 

ao0c641e master@{4}:commit(amend):who does commit? 


查看 git reflog 的 输出 和 直接 查看 日 志文 件 最 大 的 不 同 在 于 显示 顺 
序 的 不 同 ， 即 最 新 改变 放 在 了 最 前 面 显 示 ， 而 且 只 显示 每 次 改变 的 最 
终 的 SHA1 哈 希 值 。 还 有 个 重要 的 区 别 在 于 git reflog 命 令 的 输出 中 还 提 
供 了 一 个 方便 易 记 的 表达 式 <refname > @{ <n>}。 这 个 表达 式 的 


含义 是 引用 <refname> 之 前 第 <n> 次 改变 时 的 SHA1 哈 希 值 。 


那么 将 引用 master 切 换 到 两 次 变更 之 前 的 值 ， 可 以 使 用 下 面 的 命 


令 。 


重 置 master 为 两 次 改变 之 前 的 值 。 


$git reset--hard master@{2} 
HEAD is now at 4902dc3 does master follow this new commit? 


重 置 后 工作 区 中 的 文件 new-commit.txt 又 回来 了 。 


$1s 
New-commit.txt welcome.txt 


提交 历史 也 回来 了 。 


$git 1og--oneline 

4902dc3 does master follow this new commit? 
e695606 which version checked in? 

a0c641e who does commit? 

9e8a761 initialized. 


此 时 如 果 再 用 git reflog 查 看 ， 会 看 到 恢复 master 的 操作 也 记录 在 日 
让 


$git reflog show master|head-5 

4902dc3 master@{0}:master@{2}:updating HEAD 

9e8a761 master@{1}:9e8a761:updating HEAD 

e695606 master@{2}:HEAD^:updating HEAD 

4902dc3 master@{3}:commit:does master follow this new commit? 
e695606 master@{4}:commit:which version checked in? 


7.3 深入 了 解 git reset 命 令 


重 置 命令 (git reset) 是 Git 最 常用 的 命令 之 一 ， 也 是 最 危险 最 容易 


误 用 的 命令 。 来 看 看 git reset 命 令 的 用 法 。 


法 一 :git reset[-q][<commit>][--]<paths>... 
法 二 :git reset[--soft|--mixed|--hard|--merge|--keep][-q][< 
commit>] 


上 面 列 出 了 两 个 用 法 ， 其 中 <commit> 都 是 可 选项 ， 可 以 使 用 引 
用 或 提交 ID， 如 果 省 略 <commit> 则 相当 于 使 用 了 HEAD 的 指向 作为 
提交 ID 。 


上 面 列 出 的 两 种 用 法 的 区 别 在 于 ， 第 一 种 用 法 在 命令 中 包含 路 径 
<paths>。 为 了 避免 路 径 和 引用 (或 者 提交 ID) 同名 而 发 生 冲 突 ， 可 
以 在 <paths> 前 用 两 个 连续 的 短线 〈 减 号 ) 作为 分 隅 。 


第 一 种 用 法 (包含 了 路 径 <paths> 的 用 法 ) 不 会 重 置 引 用 ， 更 不 
会 改变 工作 区 ， 而 


是 用 指定 提交 状态 (<commit>) 下 的 文件 (<paths>) 替换 掉 暂 存 区 中 的 文件 。 例 如 命 
令 git reset HEAD <paths> 相当 于 取消 之 前 执行 的 git add <paths> 命令 时 改 
变 的 暂 存 区 ， 

第 二 种 用 法 不 使 用 路 径 <paths> 的 用 法 ) 则 会 重 置 引用 。 根 据 不 同 的 选项 ， 可 以 对 
暂 存 区 或 工作 区 进行 重 置 。 参照 下 面 的 版 本 库 模 型 图 (图 7-1)， 来 看 一 看 不 同 的 参数 对 第 二 
种 重 置 语法 的 影响 。 


?7-1 重 置 命 令 与 版 本 库 关 系 图 


命令 格式 : git reset [--soft | --mixed | --hard ] [<commit>] 


口 使 用 参数 --nard,， 如 :; git reset -~-hard <commit>。 
会 执行 上 图 中 的 全 部 动作 四、 名、 名 ， 即 ， 
OD 替换 引用 的 指向 。 引 用 指向 新 的 提交 ID， 
加 替换 暂 存 区 。 赫 换 后 ， 暂 存 区 的 内 容 和 引用 指向 的 上 且 录 树 一 致 . 
加 替换 工作 区 。 替 换 后 ， 工 作 区 的 内 容 变 得 和 暂 存 区 一 致 ， 也 和 HEAD 所 指向 的 目 
录 树 内 容 相 同 。 
口 使 用 参数 --soft, 如 : git reset --soft <commit>。 
会 执行 上 图 中 的 操作 外。 即 只 更 改 引 用 的 指向 ， 不 改变 暂 存 区 和 工作 区 
口 使 用 参数 --mixed 或 不 使 用 参数 (默认 为 --mixed), 如 ; git reset <commit>。 
会 执行 上 图 中 的 操作 中 和 操作 号 。 即 更 改 引 用 的 指向 及 重 置 暂 存 区 ， 但 是 不 改变 工作 区 。 
下 面 通过 一 些 示 例 ， 看 一 下 重 置 命令 的 不 同 用 法 。 
口 命令 ; git reset 
仅 用 HEAD 指向 的 目录 树 重 兽 暂 存 区 ， 工 作 区 不 会 受到 影响 ， 相 当 于 将 之 前 用 9it 
aqgq 命令 更 新 到 和 暂 存 区 的 内 容 撤 出 暂 存 区 。 引 用 也 未 改变 ， 因 为 引用 重 置 到 HEAD 
相当 于 没有 重 置 。 
口 命令 :git reset HEAL 
同上 ， 
口 命令 :git reset -- filename 


仅 将 文件 flename 的 改动 撤 出 暂 存 区 ， 暂 存 区 中 其 他 文件 不 改变 。 
相当 于 对 命令 git add filename 的 反问 操作 。 


命令 
HH 


:git reset HEAD filename 


同上 。 


公信 
0 


信念 :git reset--soft HEADA^ 


工作 区 和 暂 存 区 不 改变 ， 但 是 引用 向 前 回 退 一 次 。 当 对 最 新 提交 
的 提交 说 明 或 提交 的 更 改 不 满意 时 ， 撒 销 最 新 的 提交 以 便 重新 提交 。 


在 之 前 曾经 介绍 过 一 个 修补 提交 命令 git commit--amend， 用 于 对 
最 新 的 提交 进行 重新 提交 以 修补 错误 的 提交 说 明 或 错误 的 提交 文件 。 
修补 提交 命令 实际 上 相当 于 执行 了 下 面 两 条 命令 。 ( 注 : 文 
件 .giVCOMMIT_EDITMSG 保 存 了 上 次 的 提交 日 志 。) 


$git reset--Soft HEAD^ 
$git commit-e-F.git/COMMIT_EDITMSG 
命令 :git reset HEAD^ 
工作 区 不 改变 ， 但 是 暂 存 区 会 回 退 到 上 一 次 提交 之 前 ， 引 用 也 会 
回 退 一 次 。 


人 ~ 
9 


信念 :git reset--mixed HEADA^ 


同上 。 
命令 :git reset--hard HEAD^ 


彻 慌 撤销 最 近 的 提交 。 引 用 回 退 到 前 一 次 ， 而 且 工 作 区 和 和 暂 存 区 
都 会 回 退 到 上 一 次 提交 的 状态 。 目 上 一 次 以 来 的 提交 全 部 丢失 。 


第 8 章 ”Git 检 出 


在 上 一 章 我 们 学 习 了 重 置 命令 (git reset) 。 重 置 命令 的 一 个 用 途 
就 是 修改 引用 (如 master) 的 游标 指向 。 实 际 上 在 执行 重 置 命 令 的 时 
候 没 有 使 用 任何 参数 对 所 要 重 置 的 分 文 名 (如 master) 进行 设置 ， 这 
是 因为 重 置 命令 实际 上 所 针对 的 是 头 指针 HEAD。 之 所 以 重 置 命令 没 
有 改变 头 指针 HEAD 的 内 容 ， 是 因为 HEAD 指 网 了 一 个 引用 
refs/heads/master， 所 以 重 置 命 令 体现 为 分 支 “游标 ”的 变更 ，HEAD 本 
身 一 直 指 向 的 是 refs/heads/master， 并 没有 在 重 置 时 改变 。 


如 果 HEAD 的 内 容 不 能 改变 而 一 直 都 指向 master 分 支 ， 那 么 Git 如 
此 精妙 的 分 支 设计 忆 不 是 浪费 ? 如 有 果 HEAD 要 改变 该 如 何 改变 呢 ? 本 
草 将 学 习 检 出 命令 (git checkout) ， 该 命令 的 实质 就 是 修改 HEAD 本 
身 的 指向 ， 该 命令 不 会 影响 分 支 “ 游 标 ”( 如 master) 。 


8.1 HEAD 的 重 置 即 检 出 


HEAD 可 以 理解 为 “ 头 指 针 ”， 是 当前 工作 区 的 “基础 版 本 >”， 当 执 
行 提交 时 ，HEAD 指 向 的 提交 将 作为 新 提交 的 父 提交 。 看 看 当前 
HEAD 的 指向 。 


$cat .git/HEAD 


ref:refs/heads/master 


可 以 看 出 HEAD 指 向 了 分 支 master。 此 时 执行 git branch 会 看 到 当前 
处 于 master 分 支 。 


$git branch-v 
*master 4902dc3 does master follow this new commit? 


现在 使 用 git checkout 命 令 检 出 该 DD 的 父 提 交 ， 看 看 会 怎样 。 


$git checkout 4902dc3^ 

Note:checking out '4902dc3^ ' ， 

You are in 'detached HEAD' state.You can look around,make 
experimental 

changes and commit them,and you can discard any commits you make 
in this 

state without impacting any branches by performing another 
checkout. 

If you want to create a new branch to retain commits you 
create,you may 

do so(now or later)by using-b with the checkout command 
again.Example: 

git checkout-b new_branch_name 

HEAD is now at e695606.. .which version checked in? 


出 现 了 大 段 的 输出 ! 翻译 一 下 ，Git 肯 定 又 在 提醒 我 们 了 。 


$git checkout 4902dc3A^ 

注意 : 正 检 出 '4902dc3^ ' ， 

es Rta 状态 。 您 可 以 检查 、 测 试 和 提交 , 而 不 影响 任何 分 支 
过 执行 另外 的 一 个 checkout 检 出 指令 会 于 弃 在 此 状态 下 的 修改 和 提交 。 

如 果 想 保留 在 此 状态 下 的 修改 和 提交 ， 使 用 -参数 调用 checkout 答 出 指令 以 
创建 新 的 跟踪 分 支 。 如 : 
9 


生出 


it checkout-b new_branch_name 
处 指针 现在 指向 e695606., .提交 说 明 为 :which version checked in? 


什么 叫 作 “分 离 头 指针 ?状态 ? 查看 一 下 此 时 HEAD 的 内 容 束 明日 


$cat .git/HEAD 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 


原来 “分 离 头 指针 ”状态 指 的 就 是 HEAD 头 指针 指向 了 一 个 具体 的 
提交 ID， 而 不 是 一 个 引用 (分支) 。 


查看 最 新 提交 的 reflog 也 可 以 看 到 当 针 对 提交 执行 git checkout 命 令 
时 ，HEAD 头 指针 被 更 改 了 : 由 指向 master 分 文 变 成 了 指 癌 一 个 提交 


ID。 


$git reflog-1 
e695606 HEAD@{0}:checkout:moving from master to 4902dc3^ 


注意 上 面 的 reflog 征 HEAD 头 指针 的 变迁 记录 ， 而 非 master 分 文 。 


查看 一 下 EAD 和 master 对 应 的 提交 ID， 会 发 现 现 在 它们 指 癌 的 不 
= 
$git rev-parse HEAD master 
e695606fc5e31b2ff9038a48a3d363f4c21a3d86 
4902dc375672fbf52a226e9354100b75d4fe31e3 
前 一 个 是 HEAD 头 指针 的 指向 ， 后 一 个 是 master 分 文 的 指向 。 而 且 
还 可 以 看 到 执行 git checkout 命 令 与 执行 git reset 命 令 不 同 ， 分 文 


(master) 的 指向 并 没有 改变 ， 仍 旧 指 向 原 有 的 提交 ID 。 


现在 版 本 库 的 HEAD 是 指向 e695606 提 交 的 。 再 做 一 次 提交 ， 
HEAD 会 如 何 变化 呢 ? 具体 操作 过 程 如 下 。 


(1) 先 做 一 次 修改 : 创建 一 个 新 文件 detached-commit.txt， 添 加 
到 暂 存 区 中 。 


$touch detached-commit .txt 
$git add detached-commit.txt 


(2) 看 一 下 状态 ， 会 发 现 其 中 有 “当前 不 处 于 任何 分 支 "的 字样 
显然 这 是 因为 HEAD 处 于 “分 离 头 指针 "模式 。 
$git status 


#Not currently on any branch. 
#Changes to be committed: 


#(USe "git reset HEAD<file>..."to unstage) 
## 

#new file:detached-commit.txt 

## 


(3) 执行 提交 。 在 提交 输出 中 也 会 出 现 [detached HEAD.…….] 的 


标识 ， 这 也 是 对 用 户 的 警示 。 


$git commit-m "commit in detached HEAD mode." 
[detached HEAD acc2f69]commit in detached HEAD mode. 
0 files changed,0 insertions(+),0 deletions(-) 
create mode 100644 detached-commit.txt 


(4) 此 时 头 指 针 指向 了 新 的 提交 。 


$cat .git/HEAD 
acc2f69cf6fOae346732382c819080df75bb2191 


(5) 再 查看 一 下 日 志 会 发 现 新 的 提交 是 建立 在 之 前 的 提交 基础 上 
He 


$git log--graph--pretty=oneline 

*acc2f69cf6foae346732382c819080df75bb2191 commit in detached 
HEAD mode. 

*e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked 
in? 

*aQc641e92b1i0d8bccaled1ibf84ca80340fdefee6 who does commit? 

*ge8a761ff9dd343a1380032884f488a2422c495a initialized. 


记 下 新 的 提交 ID (acc2f69) ， 然 后 以 master 分 文 名 作为 参数 执行 


git checkout 命 令 ， 会 切换 到 master 分 文 上 。 
切换 到 master 分 文 上 ， 再 没有 之 前 大 段 的 文字 警告 。 


$git checkout master 

Previous HEAD position was acc2f69.,..commit in detached HEAD 
mode ， 

Switched to branch 'master' 


因为 HEAD 头 指针 重新 指 癌 了 分 文 ， 而 不 是 处 于 “ 断 头 模式 ”人 (分 
离 头 指针 模式 ) 。 


$cat .git/HEAD 
ref:refs/heads/master 


切换 之 后 ， 之 前 本 地 建立 的 新 文件 detached-commit.txt 不 见 了 。 


$1s 
New-commit.txt welcome.txt 


切换 之 后 ， 刚 才 的 提交 日 志 也 不 见 了 。 


$git log--graph--pretty=oneline 

*4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow 
this new commit? 

*e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked 
in? 

*aQc641e92b1i0d8bccaled1ibf84ca80340fdefee6 who does commit? 

*ge8a761ff9dd343a1380032884f488a2422c495a initialized. 


刚才 的 提交 还 存在 于 版 本 库 的 对 象 库 中 吗 ? 看 看 刚才 记 下 的 提交 
ID。 


$git show acc2f69 

commit acc2f69cf6foae346732382c819080df75bb2191 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Sun Dec 5 15:43:24 2010+0800 

commit in detached HEAD mode. 

diff--git a/detached-commit.txt b/detached-commit.txt 
new file mode 100644 

index 0000000..e69de29 


可 以 看 出 这 个 提交 现在 仍 在 版 本 库 中 。 由 于 这 个 提交 没有 被 任何 
分 文 跟 踩 到 ， 因 此 并 不 能 保证 这 个 提交 会 永久 存在 。 实 际 上 当 reflog 中 
含有 该 提交 的 日 志 过 期 后 ， 这 个 提交 随时 都 会 从 版 本 库 中 彻 瓜 清除 。 


8.2 ”挽救 分 离 头 指针 


在 “分 离 头 指针 ”模式 下 进行 的 测试 提交 除了 使 用 提交 ID 
(acc2f69) 访问 之 外 ， 不 能 通过 master 分 支 或 其 他 引用 访问 到 。 如 果 
这 个 提交 是 master 分 文 所 需要 的 ， 那 么 该 如 何 处 理 呢 ?如 果 使 用 上 一 
章 介绍 的 git reset 命 令 ， 的 确 可 以 将 master 分 文 重 置 到 该 测试 提 
交 "acc2f69"， 但 是 如 果 那 样 就 会 丢掉 master 分 支 原 先 的 提 
交 "4902dc3"。 使 用 合并 操作 (git merge) 可 以 实现 两 者 的 兼顾 。 


下 面 的 操作 会 将 提交 "acc2f69" 合 并 到 master 分 文中 来 ， 具 体操 作 
过 程 如 下 。 


(1) 确认 当前 处 于 master 分 支 。 


$git branch-v 
*master 4902dc3 does master follow this new commit? 


(2) 执行 合并 操作 ， 将 acc2f69 提 交合 并 到 当前 分 支 。 


$git merge acc2f69 

Merge made by recursive， 

0 files changed.0 insertions(+).0 deletions(-) 
create mode 100644 detached-commit.txt 


(3) 工作 区 中 多 了 一 个 detached-commit.txt 文 件 。 


$1s 
detached-commit.txt new-commit.txt welcome.txt 


(4) 查看 日 志 ， 会 看 到 不 一 样 的 分 支 图 。 即 在 e695606 提 交 开 始 
出 现 了 开发 分 文 ， 而 分 文 在 最 新 的 2b31c19 提 交 发 生 了 合并 。 


$git log--graph--pretty=oneline 

*2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69' 

人 

|*acc2f69cf6foae346732382c819080df75bb2191 commit in detached 
HEAD mode 

*|4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow 
this new commit? 

I/ 

*e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked 
in? 

*ao0c641e92b10d8bcca1led1bf84ca80340fdefee6 who does commit? 

*9e8a761ff9dd343a1380032884f488a2422c495a initialized. 


(5) 仔细 看 看 最 新 提交 ， 会 看 到 这 个 提交 有 两 个 父 提 交 。 这 就 是 
合并 的 奥秘 。 


$git cat-file-p HEAD 

tree ab676f92936000457b01507e04f4058e855d4df0 

parent 4902dc375672fbf52a226e0354100b75d4fe31e3 

parent acc2f69cf6foae346732382c819080df75bb2191 

author Jiang Xin<jiangxin@ossxp.com>1291535485+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291535485+0800 
Merge commit 'acc2f69' 


8.3 ”深入 了 解 git checkout 命 令 


检 出 命令 (git checkout) 是 Git 最 常用 的 命令 之 一 ， 同 时 也 是 一 个 


很 危险 的 命令 ， 因 为 这 条 命令 会 重 写 工作 区 。 检 出 命令 的 用 法 如 下 : 


法 一 :git checkout[-q][<commit>][--]<paths>... 
法 二 :git checkout[<branch>] 
法 三 :git checkout[-m][[-b|--orphan] <new_branch>][<start_point 


>] 


上 面 列 出 的 第 一 种 用 法 和 第 二 种 用 法 的 区 别 在 于 ， 第 一 种 用 法 在 
命令 中 包含 路 人 径 <paths>。 为 了 避免 路 径 和 3 引用 (或 者 提交 ID) 同名 
而 发 生 冲 突 ， 可 以 在 <paths> 前 用 两 个 连续 的 短线 ( 减 号 ) 作为 分 


隔 。 


第 一 种 用 法 的 <commit> 古 可 选项 ， 如 采 省 略 则 相当 于 从 暂 存 区 
(index) 进行 检 出 。 这 和 上 一 章 的 重 置 命令 大 不 相同 : 重 置 的 默认 值 
征 HEAD， 而 检 出 的 殉 认 值 是 暂 存 区 。 因 此 重 置 一 般 用 于 重 置 暂 存 区 

(除非 使 用 --hard 参 数 ， 否 则 不 重 置 工作 区 ) ， 而 检 出 命令 主要 是 覆盖 
工作 区 《如 果 <commit> 不 省 略 ， 也 会 奉 换 暂 存 区 中 相应 的 文件 ) 。 


第 一 种 用 法 〈 包 含 了 路 径 <paths > 的 用 法 ) 不 会 改变 HEAD 头 指 
针 ， 主 要 是 用 于 指定 版 本 的 文件 履 凋 工作 区 中 对 应 的 文件 。 如 条 省 略 


<commit> ， 则 会 用 辕 存 区 的 文件 覆 次 工作 区 的 文件 ， 人 否则 用 指定 提 
交 中 的 文件 履 盖 暂 存 区 和 工作 区 中 对 应 的 文件 。 


第 二 种 用 法 (不 使 用 路 径 <paths> 的 用 法 ) 则 会 改变 HEAD 头 指 

针 。 之 所 以 后 面 的 参数 写作 <branch > ， 是 因为 只 有 HEAD 切 换 到 一 个 
分 文才 可 以 对 提交 进行 跟踪 ， 否 则 仍然 会 进入 “分 离 头 指针 ”的 状态 。 
在 “分 离 头 指针 ”状态 下 的 提交 不 能 被 引用 关联 到 ， 从 而 可 能 丢失 。 所 
以 用 法 二 最 主要 的 作用 就 是 切换 到 分 文 。 如 果 省 略 <branch> 则 相当 

于 对 工作 区 进行 状态 检查 。 

第 三 种 用 法 主要 是 创建 和 切换 到 新 的 分 支 (<new_branch>)， 新 的 分 支 从 <start point> 指 
定 的 提交 开始 创建 。 新 分 支 和 我 们 熟悉 的 master 分 支 没有 什么 实质 的 不 同 ， 都 是 在 refs/heads 


命名 空间 下 的 引用 。 关 于 分 支 和 9it checkout 命令 的 这 个 用 法 会 在 后 面 的 章节 具体 介绍 . 
如 图 8-1 所 示 的 版 本 库 模 型 图 描述 了 9it checkout 实际 完成 的 操作 ， 


图 8-1 检 出 命令 与 版 本 库 关系 图 


下 面 通过 一 些 示 例 来 具体 看 一 下 检 出 命令 的 不 同 用 法 。 

口 命 令 ; git checkout branch 
检测 branch 分 支 。 要 完成 如 图 8-1 中 的 三 个 步骤， 更 新 HEAD 以 指向 branch 分 支 ， 
以 及 用 branch 指向 的 树 更 新 暂 存 区 和 工作 区 。 

口 命令 ;git checkout 
汇总 显示 工作 区 、 暂 存 区 与 HEAD 的 差 蜡 。 

口 命 令 ; git checkout HEAL 
同上 ， 

口 命令 : git checkout -- filename 
用 和 暂 存 区 中 Lename 文件 来 禾 盖 工作 区 中 的 lename 文件 。 相 当 于 取消 自 上 次 执 
行 git add filename 以 来 《如 果 执 行 过 ) 的 本 地 修改 。 
这 个 命令 很 危险 ， 因 为 对 于 本 地 的 修改 会 悄 无 声息 地 覆盖 ， 训 不 留情 。 

口 命令 ; git checkout branch -- filename 
维持 HEAD 的 指向 不 变 。 用 branch 所 指向 的 提交 中 的 lename 替换 暂 存 区 和 工作 
区 中 相应 的 文件 。 注 意 会 将 暂 存 区 和 工作 区 中 的 flename 文件 直接 覆盖 ， 

口 命令 : git checkout -~ .或 写作 git checkout . 
注意 git checkout 命令 后 的 参数 为 一 个 点 〈“.”)。 这 条 命令 最 危险 ! 会 取消 所 有 本 地 
的 修改 《相对 于 暂 存 区 )。 相 当 于 用 暂 存 区 的 所 有 文件 直接 覆盖 本 地 文件 ， 不 给 用 户 任何 
确认 的 机 会 ! 


第 9 章 ”恢复 进度 


在 之 前 “第 5 章 Git 暂 存 区 ”一 章 的 结尾 ， 曾 经 以 终结 者 (The 
Terminator) 的 口吻 说 过 : “我 会 再 回来 的 "， 会 继续 对 暂 存 区 的 探索 。 
经 过 了 前 面 三 章 对 Git 对 象 、 重 置 命令 和 检 出 命令 的 探索 ， 现 在 已 经 拥 
有 了 足够 多 的 武 右 ， 是 上 时候“ 回归 ”了 。 


本 章 “ 回 归 ” 之 后 ， 有 了 前 面 儿 章 的 基础 ， 再 看 Git 状 态 输出 中 关于 
git reset 或 git checkout 的 指示 ， 大 家 就 会 觉得 很 杀 切 、 易 如 反 掌 了 。 本 
革 还 会 重点 介绍 “回归 ”使 用 的 git stash 命 


令 。 


9.1 继续 暂 存 区 未 完成 的 实践 


人 


前 面 的 实践 ， 现 在 DEMO 版 本 库 应 该 处 于 master 分 文 上 ， 


$cd/path/to/my/workspace/demo 

$git status-sb#Git 1.7.2 及 以 上 版 本 才 支 持 -b 参 数 哦 

##master 

$git log--graph--pretty=oneline--stat 

*2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69' 

人 

|*acc2f69cf6foae346732382c819080df75bb2191 commit in detached 
HEAD mode 

[|10 files changed,0 insertions(+)，0 deletions(-) 

*|4902dc375672fbf52a226e0354100b75d4fe31e3 does master follow 
this new commit? 

|/ 

10 files changed,0 insertions(+),0©0 deletions(-) 


in? 


*e695606fc5e31b2ff9038a48a3d363f4c21a3d86 which version checked 


[welcome.txt |1+ 

|1 files changed,1 insertions(+),0©0 deletions(-) 
*agc641e92b10d8bccaled1bf84ca80340fdefee6 who does commit? 
*9e8a761ff9dd343a1380032884f488a2422c495a initialized. 
welcome.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 


还 记得 在 之 前 “第 5 章 Git 暂 存 区 ”一 章 的 结尾 是 如 何 保存 进度 的 


吗 ? 翻 回去 看 一 下 ， stash 命 令 令 用 于 保存 当前 进 


度 


和 证 


也 是 恢复 进度 要 用 的 命 
查看 保存 的 进度 用 命令 git stash list 。 


$git stash list 
stash@{0}:WIP on master:e695606 which version checked in? 


现在 就 来 恢复 进度 。 使 用 git stash pop 从 最 近 保 存 的 进度 进行 恢 


$git stash pop 
#0n branch master 
#Changes to be committed: 


#(UsSe "git reset HEAD<file>..." to unstage) 

# 

#new file:a/b/c/hello.txt 

# 

#Changes not staged for commit: 

#(USe "git add<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 

#modified:welcome.txt 

# 


Dropped refs/stash@{0}(cibd56e2565abd64a0d63450fe42aba23b673cf3) 


先 不 要 管 git stash pop 命 令 的 输出 ， 后 面 会 专题 介绍 git stash 命 令 。 
通过 查看 工作 区 的 状态 ， 可 以 发 现 进 度 已 经 找 回 了 (状态 与 进度 保存 
前 稍 有 不 同 ) 。 


$git status 
#0n branch master 
#Changes to be committed: 


#(UusSe "git reset HEAD<file>..."to unstage) 

# 

#new file:a/b/c/hello.txt 

# 

#Changes not staged for commit: 

#(USe "git add<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 

#modified:welcome.txt 

# 


此 时 再 看 Git 的 状态 输出 ， 是 否 别有一番 感觉 呢 ? 有 了 前 面 三 章 的 
基础 ， 现 在 可 以 游 刀 有 余地 应 对 各 种 情况 了 。 


(1) 以 当前 暂 存 区 的 状态 进行 提交 ， 即 只 提交 a/b/c/hello.txt， 不 


日 双关 日 六 


提交 welcome.txt。 执行 提交 : 


$git commit-m "add new file:a/b/c/hello.txt,but leave 
welcome.txt alone." 

[master 6610d05]add new file:a/b/c/hello.txt,but leave 
welcome.txt alone ， 

1 files changed,2 insertions(+),0 deletions(-) 

create mode 100644 a/b/c/hello.txt 


$git status-s 
M welcome.txt 


(2) 反悔 了 ， 回 到 之 前 的 状态 。 


用 重 置 命令 放弃 最 新 的 提交 ; 


$git reset--Soft HEAD^ 


查看 最 新 的 提交 日 志 ， 可 以 看 到 前 面 的 提交 被 抛弃 了 。 


$git 10g-1--pretty=oneline 
2b31c199d5b81099d2ecd91619027ab63e8974ef Merge commit 'acc2f69 ， 


工作 区 和 暂 存 区 的 状态 也 都 维持 在 原来 的 状态 。 


$git status-s 
A a/b/c/hello.txt 
M welcome.txt 


(3) 想 将 welcome.txt 提 区 。 


$git add welcome.txt 
$git status-s 

A a/b/c/hello.txt 

M welcome.txt 


(4) 想 将 a/b/c/hello.txt 撤 出 暂 存 区 。 


也 是 用 重 置 命令 。 


$git reset HEAD a/b/c 
$git status-s 

M welcome.txt 

32 a/ 


(5) 想 将 剩 下 的 文件 (welcome.txt) 从 暂 存 区 撤 出 ， 就 是 说 不 想 
提交 任何 东西 了 。 还 是 使 用 重 置 命 令 ， 甚 至 可 以 不 使 用 任何 参数 。 


$git reset 
Unstaged changes after reset : 
M welcome.txt 


(6) 想 将 本 地 工作 区 所 有 的 修改 清除 。 即 清除 welcome.txt 的 改 
动 ， 删 除 添 加 的 目录 a 及 下 面 的 子 目 录 和 文件 。 


清除 welcome.txt 的 改动 用 检 出 命令 。 
实际 对 于 此 例 执 行 git checkout. 也 可 以 。 


$git checkout--welcome.txt 


工作 区 显示 还 有 一 个 多 余 的 目录 a 。 


$git status 

#0n branch master 

#Untracked files: 

#(uUse "git add<file>..." to include in what will be committed) 
# 


#a/ 


删除 本 地 多 余 的 目录 和 文件 ， 可 以 使 用 git clean 命 令 。 移 来 测试 运 
行 以 便 看 看 哪些 文件 和 目 永 会 被 删除 ， 以 免 造 成 误 删 。 


$git clean-nd 
Would remove a/ 


真正 开始 强制 删除 多 余 的 目录 和 文件 。 


$git clean-fd 
Removing a/ 


整个 世界 清净 了 。 


$git status-s 


9.2 ”使 用 git stash 


命令 git stash 可 以 用 于 保存 和 恢复 工作 进度 ， 掌 握 这 个 命令 对 于 日 
常 的 工作 会 有 很 大 的 帮助 。 关 于 这 个 命令 的 最 主要 的 用 法 实际 上 通过 
前 面 的 演示 已 经 7 了解 了 。 


命令 :git stash 


瑟 


保存 当前 的 工作 进度 。 会 分 别 对 暂 存 区 和 工作 区 的 状态 进行 你 
存 。 


命令 :git stash list 


瑟 


显示 进度 列表 。 此 命令 显然 暗示 了 git stash 可 以 多 次 保存 工作 进 
度 ， 并 且 在 恢复 的 时 候 进行 选择 。 


命令 :git stash pop[--index][<stash>] 


如 果 不 使 用 任何 参数 ， 会 恢复 最 新 保存 的 工作 进度 ， 并 将 恢复 的 
工作 进度 从 存储 的 工作 进度 列表 中 清除 。 


如 果 提 供 < stash> 参 数 (来 自 于 git stash list 显 示 的 列表 ) ， 则 从 
该 <stash> 中 恢复 。 恢 复 完 毕 也 将 从 进度 列表 中 删除 <stash> 。 


选项 --index 除 了 恢复 工作 区 的 文件 外 ， 还 笑 试 恢复 暂 存 区 。 这 也 
就 是 为 什么 在 本 章 一 开始 恢复 进度 的 时 候 显示 的 状态 和 保存 进度 前 的 
略 有 不 同 。 


命令 :git stash[save[--patch][-k|--[no-]keep-index][-q|--quiet][< 
message> |]] 


这 条 命令 实际 上 是 第 一 条 git stash 命 令 的 完整 版 。 即 如 果 需 要 在 保 
存 工作 进度 的 时 候 使 用 指定 的 说 明 ， 必 须 使 用 如 下 格式 : 


git Stash save "message..." 


O 使 用 参数 --patch 会 显示 工作 区 和 HEAD 的 差异 ， 通 过 对 差异 文 
件 的 编辑 决定 在 进度 中 最 终 要 保存 的 工作 区 的 内 容 ， 通 过 编辑 差异 文 
件 可 以 在 进度 中 排除 无 关内 容 。 


O 使 用 -k 或 --keep-index 人 参数 ， 在 保存 进度 后 不 会 将 暂 存 区 重 置 。 
默认 会 将 暂 存 区 和 工作 区 强制 重 置 。 


命令 
HH 


:git stash apply[--index][<stash>] 


除了 不 删除 恢复 的 进度 之 外 ， 其 余 和 git stash pop 命 令 一 样 。 


令 :git stash drop[<stash>] 


删除 一 个 存储 的 进度 。 上 默认 删除 最 新 的 进度 。 


人 


五 


他 


证 令 :git stash clear 


删除 所 有 存储 的 进度 。 


令 :git stash branch<branchname> <stash> 


赃 


于 进度 创建 分 文 。 对 了 ， 还 没有 讲 到 分 文 呢 。;:) 


9.3 ”探秘 git stash 


了 解 一 下 git stash 的 机 理会 有 几 个 好 处 : 当 保 存 了 多 个 进度 的 时 候 
知道 从 哪个 进度 恢复 ; 绿 合 运 用 前 面 介 绍 的 Git 知 识 点 ， 了 解 Git 的 源 
码 ，Git 将 不 再 神秘 。 


在 执行 git stash 命 令 时 ，Git 实 际 调用 了 一 个 脚本 文件 实现 相关 的 
功能 ， 这 个 脚本 的 文件 名 就 是 git-stash。 看 看 git-stash 安 装 在 哪里 了 。 


$git--exec-path 
/usr/l1ib/git-core 


如 有 果 查 看 一 下 这 个 目录 ， 您 会 震惊 的 。 


$1ls/usr/l1ib/git-core/ 

git git-help git-reflog 

git-add git-http-backend git-relink 
git-add--interactive git-http-fetch git-remote 
git-am git-http-push git-remote-ftp 
git-annotate git-imap-send git-remote-ftps 
git-apply git-index-pack git-remote-http 


, ,省 略 40 余 行 .. . 


实际 上 在 1.5.4 之 前 的 版 本 中 ，Git 会 将 这 样 的 一 百 多 个 以 git-< cmd 
> 格式 命名 的 程序 安 儿 到 可 执行 路 径 中 ， 而 这 样 做 的 唯一 好 处 就 是 不 
用 借助 任何 扩展 机 制 束 可 以 实现 命令 行 补 齐 ， 即 键入 git- 后 ， 连 续 两 次 


键入 <Tab> 键 ,就 可 以 把 这 一 百 多 个 命令 显示 出 来 。 这 种 方式 随 着 
Git 了 于 命令 的 增加 显得 越 来 越 混 乱 ， 因 此 从 1.5.4 版 本 开始 ， 不 再 提供 
gitr<cmd> 格 式 的 命令 ， 而 是 用 唯一 的 git 命 令 。 而 之 前 的 名 为 git-< 
cmd> 的 子 命令 则 保存 在 非 可 执行 目 示 下 ， 由 Git 负 责 加 载 。 


在 后 面 的 章节 中 偶尔 会 看 到 形 如 git- < cmd> 字样 的 名 称 ， 以 及 同 
时 存在 的 git< cmd> 命令 。 可 以 这 样 理解 git-<cmd> 作为 软件 本 身 
的 名 称 ， 而 其 命令 行为 git< cmd> 。 


最 初 很 多 Git 命 令 都 是 用 Shell 或 Penl 脚 本 语言 开发 的 ， 在 Git 的 发 展 
中 一 些 对 运行 效率 要 求 高 的 命令 用 C 语 言 改写 。 而 git-stash (至少 在 Git 
1.7.4 版 本 ) 还 是 使 用 Shell 脚 本 开发 的 ， 人 研究 它 比 研 究 用 C 写 的 命令 要 
简单 得 多 。 


$file/usr/l1ib/git-core/git-stash 
/usr/lib/git-core/git-stash:POSIX shell script text executable 


解析 git-stash 脚 本 会 比较 枯燥 ， 还 是 通过 运行 一 些 示 例 来 理解 更 好 
一 此 。 


当前 的 进度 保存 列表 是 空 的 。 


$git stash list 


下 面 在 工作 区 中 做 一 些 改 动 。 


$echo Bye-Bye.> >welcome.txt 
$echo hello.>hack-1.txt 
$git add hack-1.txt 

$git status-s 

A hack-1.txt 

M welcome.txt 


可 见 和 暂 存 区 中 已 经 添加 了 新 增 的 hack-1.txt， 修 改过 的 welcome.txt 
并 未 添加 到 暂 存 区 。 执 行 git stash 保 存 一 下 工作 进度 。 


$git stash save "hack-1:hacked welcome.txt,newfile hack-1.txt" 

Saved working directory and index state On master:hack-1:hacked 
welcome.txt,newfile hack-1.txt 

HEAD is now at 2b31c19 Merge commit 'acc2f69' 


工作 区 恢复 了 修改 前 的 原貌 (实际 上 用 了 git reset--hard HEAD 命 
令 ) ， 文 件 welcome.txt 的 修改 不 见 了 ， 文 件 hack-1.txt 整 个 都 不 见 了 。 


$git status-s 
$1s 
detached-commit.txt new-commit.txt welcome.txt 


再 做 一 个 修改 ， 并 笑 试 保存 进度 。 


$echo fix.>hack-2.txt 
$git stash 
No local changes to save 


进度 保存 失败 ! 可 见 本 地 没有 被 版 本 控制 系统 跟 路 的 文件 并 不 能 
保存 进度 。 因 此 本 地 新 文件 需要 先 执 行 深 加 操作 ， 然 后 再 执行 git stash 


J 


$git add hack-2.txt 

$git stash 

Saved working directory and index state WIP on master:2b31c19 
Merge commit 

"acCc2f69 ， 

HEAD is now at 2b31c19 Merge commit 'acc2f69 


不 用 看 惑 知 道 工 作 区 再 次 恢复 原状 。 如 采 这 时 执行 git stash list 会 
看 到 有 两 次 进度 保存 。 


$git stash list 
stash@{0}:WIP on master:2b31c19 Merge commit 'acc2f69' 
stash@{1}:0n master:hack-1:hacked welcome.txt,newfile hack-1.txt 


从 上 面 的 输出 中 可 以 得 出 两 个 结论 


在 用 git stash 命 令 保存 进度 时 ， 如 采 提 供 说 明 则 更 容易 通过 进度 列 
表 找 到 保存 的 进度 。 


每 个 进度 的 标识 都 是 stash@{ <n> } 格 式 ， 像 极 了 前 面 介 绍 的 
人 


实际 上 ，git stash 束 是 用 前 面 介绍 的 引用 和 引用 变更 日 志 
(reflog) 来 实现 的 。 


$1s-1.git/refs/stash.git/logs/refs/stash 

-rw-r--r--1 jiangxin jiangxin 364 Dec 6 
16:11.git/logs/refs/stash 

-rw-r--r--1 jiangxin jiangxin 41 Dec 6 16:11.git/refs/stash 


那么 在 “第 7 章 Git 重 置 "一 草 中 学 习 的 reflog 可 以 派 上 用 场 了 。 


$git reflog show refs/stash 

e5cocdc refs/stash@{0}:WIP on master:2b31c19 Merge commit 
'acc2f69' 

6cec9db refs/stash@{1}:On master:hack-1:hacked 
welcome.txt,newfile hack-1.txt 


对 照 git reflog 的 结果 和 前 面 git stash list 的 结果 ， 可 以 肯定 用 git 
stash 保 存 进 度 ， 实 际 上 会 将 进度 保存 在 引用 refs/stash 所 指 癌 的 提交 
中 。 多 次 的 进度 保存 ， 实 际 上 相当 于 引用 refs/stash 一 次 又 一 次 的 变 
化 ， 而 refs/stash 引 用 的 变化 由 reflog ( 即 .git/logs/refs/stash) 所 记录 下 
来 。 这 个 实现 是 多 么 简单 而 巧妙 啊 。 


一 个 痢 的 疑问 又 出 现 了 ， 如 何在 引用 refs/stash 中 同时 保存 和 暂 存 区 
的 进度 和 工作 区 中 的 进度 呢 ? 得 看 一 下 引用 refs/stash 的 提交 历史 能 够 
看 出 端倪 。 


$git log--graph--pretty=raw refs/stash-2 

*commit e5cocdc2dedc3e50e6b72a683d928e19a1d9de48 

|\tree 780c22449b7ff67e2820e09a6332c360ddc80578 

| lparent 2b31c199d5b81099d2ecd91619027ab63e8974ef 
||parent cs5edbdcc90addb06577ff60f644acd1542369194 
|lauthor Jiang Xin<jiangxin@ossxp.com>1291623066+0800 

| |committer Jiang Xin<jiangxin@ossxp.com>1291623066+0800 


| | 
[||IWIP on master:2b31c19 Merge commit 'acc2f69' 
| | 


|*commit c5edbdcc90addb06577ff60f644acd1542369194 

|/tree 780c22449b7ff67e2820e09a6332c360ddc80578 

|parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 

|author Jiang Xin<jiangxinQ@ossxp.com>1291623066+0800 
|committer Jiang Xin<jiangxin@ossxp.com>1291623066+0800 


|index on master:2b31c19 Merge commit "acc2f69 


从 提交 历史 中 可 以 看 到 进度 保存 的 最 新 提交 是 一 个 合并 提交 。 最 
新 的 提交 说 明 中 有 WIP 字 样 (是 Work In Progess 的 简称 ， 代 表 了 工作 
区 进度 。 而 最 新 提交 的 第 二 个 父 提交 (提交 历史 中 显示 为 第 二 个 提 


交 ) 有 index on master 字 样 ， 说 明 这 个 提交 代表 着 暂 存 区 的 进度 。 


但 是 提交 历史 中 的 两 个 提交 都 指 问 了 同一 个 树 
780c224.…..， 这 是 因为 最 后 一 次 做 进度 保存 时 工作 区 相对 和 暂 存 区 没有 
改变 ， 这 使 得 工作 区 和 和 暂 存 区 在 引用 refs/stash 中 的 存储 变 得 有 些 扑 朔 
迷离 。 别 还 了 第 一 次 进度 保存 工作 区 、 暂 存 区 和 版 本 库 都 是 不 同 的 ， 
可 以 用 于 验证 关于 refs/stash 实 现 机 制 的 判断 。 


tree 


第 一 次 进度 保存 可 以 使 用 reflog 中 的 语法 ， 即 用 refs/stash@{1} 来 
访问 ， 也 可 以 用 简称 stash@{1}。 下 面 区 来 研究 一 下 第 一 次 的 进度 保 
种 


$git log--graph--pretty=raw stash@{1}-3 

*commit 6cec9db44af38d01abe7b5025a5190c56fdocf49 

|\tree 7250f1i86c6aa3e2d1456d7fa915e529601f21d71 

| lparent 2b31c199d5b81099d2ecd91619027ab63e8974ef 

| lparent 4560d76c19112868a6a5692bf9379de09c0452b7 
|lauthor Jiang Xin<jiangxin@ossxp.com>1291622767+0800 

| |committer Jiang Xin<jiangxin@ossxp.com>1291622767+0800 


| | 
[||on master:hack-1:hacked welcome.txt,newfile hack-1.txt 
| | 


|*commit 4560d76c19112868a6a5692bf9379de09c0452b7 
|/tree 5d4dd328187e119448c9171f99cf2e507e91a6c6 
|parent 2b31c199d5b81099d2ecd91619027ab63e8974ef 
|author Jiang Xin<jiangxin@ossxp.com>1291622767+0800 


|committer Jiang Xin<jiangxin@ossxp.com>1291622767+0800 
| 


|index on master:2b31c19 Merge commit "acc2f69 

| 

*commit 2b31c199d5b81099d2ecd91619027ab63e8974ef 

[|\tree ab676f92936000457b01507e04f4058e855d4df0 

| lparent 4902dc375672fbf52a226e0354100b75d4fe31e3 
||parent acc2f69cf6foae346732382c819080df75bb2191 
|lauthor Jiang Xin<jiangxin@ossxp.com>1291535485+0800 

| |committer Jiang Xin<jiangxin@ossxp.com>1291535485+0800 


| | 
| IMerge commit "acc2f69 


果然 上 面 显 示 的 三 个 提交 对 应 的 三 棵 树 各 不 相同 。 查 看 一 下 差 

。 用 “ 原 基 线 ” 代 表 进 度 保存 时 版 本 库 的 状态 ， 即 提交 2b31c199; 
用 “ 原 暂 存 区 ”代表 进度 保存 时 暂 存 区 的 状态 ， 即 提交 4560d76; 用 “ 原 
工作 区 ”代表 进度 保存 时 工作 区 的 状态 ， 即 提交 6cec9db 。 


原 基线 和 原 暂 存 区 的 差异 比较 。 


$git diff stash@{1}^2^stash@{1}^2 
diff--git a/hack-1.txt b/hack-1.txt 
new file mode 100644 

index 0000000. .25735f5 

---/dev/null 

+++b/hack-1.txt 

Q@@-0,0+1@@ 

+hello. 


原 暂 存 区 和 原 工 作 区 的 差异 比较 。 


$git diff stash@{1}^2 stash@{1} 
diff--git a/welcome.txt b/welcome.txt 
index fd3c069..51dbfd2 100644 
---a/welcome. txt 

+++b/welcome .txt 


QQ-1， 2+1, 3Q0 


Hello. 
Nice to meet you. 
+Bye -Bye. 


原 基线 和 原 工作 区 的 差异 比较 。 


$git diff stash@{1}^1 stash@{1} 
diff--git a/hack-1.txt b/hack-1.txt 
new file mode 100644 

index 0000000. .25735f5 

---/dev/null 

+++b/hack-1.txt 

QQ@-0, 0+166 

+hello. 

diff--git a/welcome.txt b/welcome.txt 
index fd3c069..51dbfd2 100644 
---a/welcome.txt 

+++b/welcome .txt 

QQ@-1, 2+1, 3@Q@ 

Hello. 

Nice to meet you. 

+Bye -Bye. 


用 stash@{1} 来 恢复 进度 。 


$git stash apply stash@{1} 
#0n branch master 
#Changes to be committed: 


#(USe "git reset HEAD<file>..."to unstage) 

# 

#new file:hack-1.txt 

# 

#Changes not staged for commit: 

#(USe "git add<file>..."to update what will be committed) 

#(USe "git checkout--<file>..."to discard changes in working 
directory) 

# 


#modified:welcome.txt 
# 


显示 进度 列表 ， 然 后 删除 进度 列表 。 


$git stash list 

stash@{0}:WIP on master:2b31c19 Merge commit 'acc2f69' 
stash@{1}:0n master:hack-1:hacked welcome.txt,newfile hack-1.txt 
$git stash clear 


删除 进度 列表 之 后 ， 会 发 现 stash 相 关 的 引用 和 reflog 都 不 见 了 。 


$1s-1.git/refs/stash.git/logs/refs/stash 
ls:cannot access.git/refs/stash:No such file or directory 
ls:cannot access.git/logs/refs/stash:No such file or directory 


通过 上 面 的 这 些 分 析 ， 有 一 定 Shell 编 程 基 础 的 读者 就 可 以 党 试 研 
完 git-stash 的 代码 了 ， 在 人 研究 过 程 中 你 可 能 会 有 新 的 发 现 。 


第 10 章 ”Git 基 本 操作 


之 前 的 实践 选取 的 示例 都 非常 简单 ， 基 本 上 都 是 增加 和 修改 文本 
文件 ， 而 现实 情况 要 复杂 得 多 ， 需 要 应 对 各 种 情况 : 文件 删除 、 文 件 
复制 、 文 件 和 移动、 目录 的 组 织 、 二 进 制 文件 、 误 删 文件 的 恢复 ， 等 


4 。 
于 


本 章 要 用 一 个 更 为 真实 的 例子 ， 通 过 对 Hello World 程 序 源 代码 的 
版 本 控制 ， 来 介绍 工作 区 中 其 他 的 一 些 常 用 操作 。 首 先 我 们 会 删除 之 
前 历次 实践 在 版 本 库 中 留 下 的 “垃圾 ”数据 ， 然 后 再 在 其 中 创建 一 些 真 
实 的 代码 ， 并 对 其 进行 版 本 控制 。 


101 竺 来 全 人 小 2 


马上 就 要 和 之 前 实践 遗留 的 数据 告别 了 ， 告 别 之 前 是 不 是 要 留 个 
影 呢 ? 在 Git 里 ，“ 留 影 * 用 的 命令 叫 作 tag， 更 加 专业 的 术语 叫 作 “ 里 程 
碑 ”( 打 tag， 或 打 标签 ) 。“ 留 影 "操作 如 下 ， 


$cd/path/to/my/workspace/demo 
$git tag-m"Say bye-bye to all previous practice."old practice 


本 章 还 不 打算 评 细 介绍 里 程 碑 的 奥秘 ， 只 要 知道 里 程 碑 无 非 也 是 
一 个 引用 ， 通 过 记录 提交 ID (或 者 创建 Tag 对 和 象 ) 来 为 当前 版 本 库 的 


状态 进行 “留影 ”。 


$1s.git/refs/tags/old_practice 
.git/refs/tags/old_practice 

$git rev-parse refs/tags/old practice 
41bd4e2cceof8baa9bb4cdda62927b408c846cd6 


留 过 影 之 后 ， 可 以 执行 git describe 命 令 将 最 新 提交 显示 为 一 个 易 
记 的 名 称 。 显 示 的 时 候 会 选取 离 该 提交 最 近 的 里 程 碑 作为 “基础 版 本 
号 ”， 后 面 附加 标识 距离 “基础 版 本 ”的 数字 ， 以 及 该 所 交 的 SHA1 哈 希 
值 缩写 。 因 为 最 新 的 提交 上 恰好 被 打 了 一 个 “里 程 碑 ”"， 所 以 直接 显 
示 “ 里 程 碑 ”的 名 称 。 这 个 技术 会 在 后 面 的 示例 代码 中 多 次 用 到 。 


$git describe 
old_practice 


10.2 ”删除 文件 


看 看 版 本 库 当 前 的 状态 ， 暂 存 区 和 工作 区 都 包含 修改 。 


$git status-s 
A hack-1.txt 
M welcome.txt 


在 这 个 暂 存 区 和 工作 区 都 包含 文件 修改 的 情况 下 ， 使 用 删除 命令 
更 具有 挑战 性 。 删 除 命 令 有 多 种 使 用 方法 ， 有 的 方法 很 巧妙 ， 而 有 的 
方法 则 需要 更 多 的 输入 。 为 了 分 别 介绍 不 同 的 删除 方法 ， 还 要 使 用 上 
一 章 介绍 的 进度 保存 (git stash) 命令 。 


保存 进度 。 


$git stash 

Saved working directory and index state WIP on master:2b31c19 
Merge commit 

'acc2f69' 

HEAD is now at 2b31c19 Merge commit 'acc2f69' 


再 恢复 进度 。 注 意 不 要 使 用 git stash pop， 而 是 使 用 git stash 
apply， 因 为 这 个 保存 的 进度 要 被 多 次 用 到 。 


$git stash apply 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
# 


#new file:hack-1.txt 


# 

#Changed but not updated: 

#(USe "git add<file>..."to update what will be committed) 

#(USe "git checkout--<file>..."to discard changes in working 
directory) 

# 

#modified:welcome.txt 

# 


10.2.1 本 地 删除 不 是 真 的 删除 


当前 工作 区 的 文件 有 : 


$1sS 
detached-commit.txt 
hack-1.txt 
New-commit .txt 
welcome.txt 


直接 在 工作 区 删除 这 些 文件 ， 会 如 何 呢 ? 


$rm* .txt 


通过 下 面 的 命令 ， 可 以 看 到 在 暂 存 区 (版 本 库 ) 中 的 文件 仍然 存 
在 ， 并 未 删除 。 


$git ls-files 
detached-commit.txt 
hack-1.txt 
New-commit .txt 
welcome.txt 


从 文件 的 状态 来 看 ， 文 件 只 是 在 本 地 进行 了 删除 ， 尚 未 添加 到 和 暂 
存 区 (提交 任务 ) 中 。 也 就 是 说 : 直接 在 工作 区 删除 ， 对 和 暂 存 区 和 版 
本 库 没 有 任何 影响 。 


$git status 
#0n branch master 
#Changes to be committed: 


#(UusSe "git reset HEAD<file>..."to unstage) 

# 

#new file:hack-1.txt 

# 

#Changed but not updated: 

#(USe "git add/rm<file>..."to update what will be committed) 

#(USe "git checkout--<file>..."to discard changes in working 
directory) 

# 


#deleted:detached-commit .txt 
#deleted:hack-1.txt 
#deleted:new-commit .txt 
#deleted:welcome.txt 

## 


从 Git 状 态 输出 中 可 以 看 出 ， 本 地 删除 如 有 果 要 反映 在 暂 存 区 中 应 该 
用 git rm 命令 ， 对 不 想 删 除 的 文件 执行 git checkout--<file> ， 可 以 让 文 
件 在 工作 区 重 现 。 


10.2.2 ”执行 git rm 命令 删除 文件 


好 吧 ， 按 照 上 面 状态 输出 的 内 容 ， 将 所 有 的 文本 文件 删除 。 执 行 
下 面 的 命令 : 


$git rm detached-commit ,txt hack-1.txt new-commit.txt 
welcome.txt 

rm 'detached-commit.txt' 

rm 'hack-1.txt' 

rm 'new-commit.txt' 

rm 'welcome.txt' 


再 看 一 看 状态 : 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
## 

#deleted:detached-commit. txt 
#deleted:new-commit .txt 
#deleted:welcome.txt 

## 


删除 动作 加 入 了 和 暂 存 区 。 这 时 执行 提交 动作 ， 束 从 真正 意义 上 的 
行 了 文件 删除 。 


$git commit-m "delete trash files.(using:git rm)" 
[master 483493aldelete trash files. (using:git rm) 
1 files changed,0 insertions(+),2 deletions(-) 
delete mode 100644 detached-commit.txt 

delete mode 100644 new-commit.txt 

delete mode 100644 welcome.txt 


不 过 不 要 担心 ， 文 件 只 是 在 版 本 库 的 最 新 提 交 中 被 删除 了 ， 在 历 
史 提 区 中 尚 在 。 可 以 通过 下 面 的 命令 查看 历史 版 本 的 文件 列表 。 


$git ls-files--with-tree=HEADA^ 
detached-commit.txt 

New-commit .txt 

welcome.txt 


也 可 以 查看 在 历史 和 版 本 中 尚 在 的 删除 文件 的 内 容 。 


$git cat-file-p HEAD^:welcome.txt 
Hello. 
Nice to meet you. 


10.2.3 ”命令 git add-u 快 速 标记 删除 


在 前 面 执行 git rm 命令 时 ， 写 下 了 所 有 要 删除 的 文件 名 ， 好 长 的 命 
> 啊 ! 能 不 能 简化 些 ? 实际 上 git add 就 可 以 ， 即 使 用 -u 参 数 调用 git add 
命令 ， 伟 义 是 将 本 地 有 改动 (包括 修改 和 删除 ， 的 文件 标记 到 暂 存 
区 。 为 了 重 现 刚 才 的 场景 ， 先 使 用 重 置 命令 抛弃 最 狐 的 提交 ， 再 使 用 
进度 恢复 到 之 前 的 状态 ， 具 体操 作 过 程 如 下 。 


公心 


(1) 丢弃 之 前 测试 删除 的 试验 性 提交 


$git reset--hard HEADA^ 
HEAD is now at 2b31c19 Merge commit 'acc2f69' 


(2) 恢复 保存 的 进度 。 (参数 -q 使 得 命令 进入 安静 模式 。) 


$git stash apply-d 


(3) 然后 删除 本 地 文件 ， 状 态 显 示 出 依然 只 是 在 本 地 删除 了 文 
件 ; 御 友 区 中 鸭 文件 仍 人 在 


$rm* ,txt 

$git status-s 

D detached-commit.txt 
AD hack-1.txt 

D new-commit .txt 

D welcome.txt 


(4) 执行 git add-u 命 令 可 以 将 (被 版 本 库 追 踪 的 ) 本 地 文件 的 变 
更 〈 修 改 、 删 除 ) 全 部 记录 到 暂 存 区 中 。 


$git add-u 


(5) 查看 状态 ， 可 以 看 到 工作 区 删除 的 文件 全 部 被 标记 为 下 次 提 
交 时 删除 。 


$gitstatus-s 

D detached-commit.txt 
D new-commit .txt 

D welcome.txt 


(6) 执行 提交 ， 删 除 文 件 。 


$git commit-m "delete trash files.(using:git add-u)" 
[master 7161977]delete trash files.(using:git add-u) 
1 files changed,0 insertions(+),2 deletions(-) 
delete mode 100644 detached-commit.txt 

delete mode 100644 new-commit.txt 

delete mode 100644 welcome.txt 


10.3 ”恢复 删除 的 文件 


经 过 了 上 面 的 文件 删除 ， 工 作 区 已 经 没有 文件 了 。 为 了 说 明文 件 
移动 ， 现 在 恢复 一 个 删除 的 文件 。 前 面 已 经 说 过 执行 了 文件 删除 并 所 
交 ， 只 是 在 最 新 的 提交 中 删除 了 文件 ， 历 史 提 交 中 文件 仍然 保留 ， 可 
以 从 历史 提交 中 提取 文件 。 执 行 下 面 的 命令 可 以 从 历史 (前 一 次 提 
交 ) 中 恢复 welcome.txt 文 件 。 


$git cat-file-p HEAD~1:welcome.txt>welcome.txt 
也 可 以 使 用 git show 命 令 取 代 git cat-file-p 命 令 ， 歼 果 相 同 。 
$git Show HEAD~1:welcome.txt>welcome.txt 
使 用 git checkout 命 令 则 最 为 简 清 实用 。 
$git checkout HEAD~1--welcome.txt 


上 面 的 命令 中 出 现 的 HEAD~1 即 相当 于 HEADA^ 都 指 的 是 HEAD 的 
上 一 次 提交 。 执 行 git add-A 命 令 会 将 工作 区 中 的 所 有 改动 及 新 增 文件 
添加 到 和 暂 存 区 ， 这 也 是 一 个 常用 的 技巧 。 执 行 下面 的 命令 后 ， 将 恢复 
过 来 的 welcome.txt 文 件 添加 回 和 暂 存 区 。 


$git add-A 


$git status-s 
A welcome.txt 


执行 提交 操作 ， 文 件 welcome.txt 义 回来 了 。 


$git commit-m "restore file:welcome.txt" 
[master 63992fg0]jrestore file:welcome.txt 

1 files changed,2 insertions(+),0 deletions(-) 
create mode 100644 welcome.txt 


通过 再 次 添加 的 方式 恢复 被 删除 的 文件 是 最 目 然 的 恢复 方法 。 其 
他 版 本 控制 系统 如 CVS 也 采用 同样 的 方法 恢复 删除 的 文件 ， 但 是 有 的 
版 本 控制 系统 (如 Subversion) 如 果 这 样 操作 会 有 严重 的 副作用 一 一 文 
件 变 更 历史 被 人 为 地 制 神 ， 而 且 还 会 造成 服务 器 存 储 空间 的 浪费 。Git 
通过 添加 方式 反 删除 文件 没有 副作用 ， 这 是 因为 在 Git 的 版 本 库 中 相同 
内 容 的 文件 保存 在 一 个 plob 对 象 中 ， 即 便 是 内 容 不 同 的 blob 对 象 通过 
对 象 库 打包 也 会 进行 存储 优化 。 


10.4 移动 文件 


通过 将 welcome.txt 改 名 为 README 文 件 来 测试 一 下 在 Git 中 如 何 移 


动 文件 。Git 提 供 了 git mv 命令 完成 改名 操作 。 


$git mv welcome.txt README 


可 以 从 当前 的 状态 中 看 到 改名 的 操作 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
# 


#renamed:welcome.txt-> README 
# 


提交 改名 操作 ， 在 提交 输出 中 可 以 看 到 改名 前 后 两 个 文件 的 相似 
(百分比 ) 


$git commit-m "改名 测试 " 

[master 7aa5ac1] 改 名 测试 

1 files changed,0 insertions(+),0 deletions(-) 
rename welcome.txt=>README(100%) 


从 提交 日 志 中 出 现 的 文件 相似 度 可 以 看 出 ，Git 的 改名 操作 得 益 于 


Git 对 文件 追踪 的 强大 文 持 (文件 内 容 作 为 blob 对 象 保存 在 对 象 库 


I 


。 改名 操作 相当 于 对 旧 文 件 执行 删除 ， 对 新 文件 执行 添加 。 实 际 


以 git rm 和 git add 两 条 命令 取 而 代 


上 完全 可 以 不 使 用 git mv 命令 ， 而 是 
命令 是 否 可行 ， 先 撤销 之 前 进行 的 提交 。 


之 。 为 了 试验 不 使 用 git mv 命令 
撤销 之 前 测试 文件 移动 的 提交 。 


$git reset--hard HEADA^ 

HEAD is now at 63992f0 restore file:welcome.txt 
撤销 之 后 welcome .txt 文 件 又 回来 了 。 

$git status-s 

$git ls-files 

welcome.txt 


新 的 改名 操作 不 使 用 git mv 命令 ， 而 是 直接 在 本 地 改名 (文件 移 
动 ) ， 将 welcome.txt 改 名 为 README 。 


$mv welcome ,txt README 
$git status-s 

D welcome.txt 

?7? README 


为 了 考验 一 下 Git 的 内 容 退 中 能 力 ， 再 修改 一 下 改名 后 的 README 
文件 ， 即 在 文件 末尾 退 加 一 行 。 


$echo "Bye-Bye."> >README 


可 以 使 用 前 面 介绍 的 git add-A 命 令 。 相 当 于 对 修改 文件 执行 git 
add， 对 删除 文件 执行 gitrm， 对 本 地 新 增 文件 执行 git add 。 


$git add-A 


查看 状态 ， 也 可 以 看 到 文件 重 命名 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
# 

#renamed:welcome.txt-> README 

## 


执行 提交 。 


$git commit-m "README is from welcome.txt." 
[master c024f34]README is from welcome.txt. 

1 files changed,1 insertions(+),0 deletions(-) 
rename welcome.txt=>README(73%) 


这 次 提交 中 也 看 到 了 重 命名 操作 ， 但 是 重 命名 相似 度 不 是 10096， 


而 是 73%， 这 是 因为 重 命名 后 的 文件 又 追加 了 一 行 。 


10.5 一 个 显示 版 本 号 的 Hello World 
在 本 章 的 一 开始 为 纪念 前 面 的 实践 留 了 一 个 影 ， 叫 作 
old_practice。 现 在 再 次 执行 git describe 看 一 下 现在 的 版 本 号 。 


$git describe 
old_practice-3-gc024f34 


也 就 是 说 : 当前 工作 区 的 版 本 是 “留影 "后 的 第 三 个 版 本 ， 提 交 ID 
是 c024f34 。 


下 面 的 命令 可 以 在 提交 日 志 中 显示 提交 对 应 的 里 程 碑 (Tag) 。 其 
中 参数 --decorate 可 以 在 提交 ID 的 旁边 显示 该 提交 关联 的 引用 (里 程 碑 


$git log--oneline--decorate-4 
cO24f34(HEAD, master )README is from welcome.txt. 
63992f0 restore file:welcome.txt 

7161977 delete trash files.(using:git add-u) 
2b31c1i9(tag:old practice)Merge commit "acc2f69 


命令 git describe 的 输出 可 以 作为 软件 版 本 号 ， 这 个 功能 非常 有 
用 。 因 为 这 样 可 以 很 容易 地 实现 将 发 布 的 软件 包 版 本 和 版 本 库 中 的 代 
码 对 应 在 一 起 ， 当 发 现 软 件 包 包含 Bug 时 ， 可 以 最 快 、 最 准确 地 对 应 
到 代码 上 。 


下 面 的 Hello World 程 序 就 实现 了 这 个 功能 。 创 建 日 录 src， 并 在 src 
目录 下 创建 以 下 三 个 文件 : 


(1) 文件 : src/main.c 


没 错 ， 下 面 几 行 代 码 就 是 这 个 程序 的 主 代码 ， 和 输出 相关 的 代码 
就 两 行 ， 一行 显示 "Hello,world."， 男 外 一 行 显示 软件 版 本 。 在 显示 软 
件 版 本 时 用 到 了 宏 _-VERSION， 这 个 宏 的 来 源 参 考 下 一 个 文件 。 


#include "version.h" 
#include<stdio.h> 

int 

main() 

{ 
printf("Hello,world.\n"); 


printf("version:%s.\n",_VERSION); 
return 0; 


} 


(2) 文件 : src/version.h.in 


没 销 ， 这 个 文件 名 的 后 缀 是 .h.in。 这 个 文件 其 实 是 用 于 生成 文件 
version.h 的 模板 文件 。 在 由 此 模板 文件 生成 version.h 的 过 程 中 ， 
_VERSION 的 值 "< version > "会 动态 替换 。 


#ifndef HELLO_WORLD_VERSION_H 
#define HELLO_WORLD_VERSION_H 
#define VERSION "<version>" 
#endif 


(3) 文件 : src/Makefile 


这 个 文件 看 起 来 很 复杂 ， 而 且 要 注意 所 有 缩 进 都 是 使 用 一 个 < Tab 
> 键 完 成 的 缩 进 ， 千 万 不 要 错误 地 写成 空格 ， 因 为 这 是 Makefile 的 格 
式 要 求 。 这 个 文件 除了 定义 如 何 由 代码 生成 可 执行 文件 hello 之 外 ， 
定义 了 如 何 将 模板 文件 version.h.in 转 换 为 version.h。 i 
describe 命 令 的 输出 蔡 换 模板 文件 中 的 <version>> 字 符 串 。 


OBJECTS=main.o 

TARGET=hello 

all:$(TARGET) 

$(TARGET):$(OBJECTS) 

$(CC)-o$@$A 

main.o:main.c version.h 
version.h:new_header 

new_header : 

@sed-e "s/<version>/$$(git describe)/g"\ 
<version.h.in>version.h.tmp 

@if diff-q version.h.tmp version.h>/dev/null 2>&1; \ 
then\ 

rm version.h.tmp; \ 

else\ 

echo "version.h.in=>version.h"; \ 

mv version.h.tmp version.h; \ 

fi 

clean: 

rm-f$(TARGET)$(OBJECTS)version.h 
.PHONY:all clean 


上 述 三 个 文件 创建 完毕 之 后 ， 进 入 到 src 目 了 永 ， 试 着 运行 一 下 。 先 
执行 make 编 译 ， 再 运行 编译 后 的 程序 hello 。 


$cd src 
$make 
version.h.in=>version.h 


cCc-Cc-o main.o main.c 

cCc-o hello main.o 

$./hello 

Hello,world. 
version:old_practice-3-gc024f34. 


10.6 ”使 用 git add-i 选 择 性 添加 


刚刚 创建 的 Hello World 程 序 还 没有 添加 到 版 本 库 中 ， 在 src 目 录 下 
有 下 列 文件 : 
$cd/path/to/my/workspace/demo 


$1s src 
hello main.c main.o Makefile version.h version.h.in 


这 些 文件 中 hello、main.o 和 version.h 都 是 在 编译 时 生成 的 文件 ， 不 
应 该 加 入 到 版 本 库 中 。 那 么 选择 性 添加 文件 除了 针对 文件 逐一 使 用 git 
add 命 令 外 ， 还 有 其 他 办 法 吗 ? 通过 使 用 -i 参 数 调用 git add 束 是 一 个 办 
法 ， 它 提供 了 一 个 交互 式 的 界面 。 


执行 git add-i 命 令 ， 进 入 一 个 交互 式 界面 ， 首 先 显示 的 古 工作 区 状 
态 。 显 然 因为 版 本 库 进 行 了 清理 ， 所 以 显得 很 < 干将”。 


$git add-i 

staged unstaged path 

***CommandS*** 

1:Status 2:update 3:revert 4:add untracked 
5:patch 6:diff 7:quit 8:help 

What now> 


交互 式 界面 显示 了 命令 列表 ， 可 以 使 用 数字 或 加 亮 显 示 的 命令 首 
字母 ， 选 择 相应 的 功能 。 对 于 此 例 需 要 将 新 文件 加 入 到 版 本 库 中 ， 所 


以 选择 <4"。 


What now>4 
1:src/Makefile 
2:src/hello 
3:src/main.c 
4:src/main.o 
5:src/version.h 
6:src/version.h.in 
Add untracked>> 


当选 择 了 “4” 之 后 ， 就 进入 了 "Add untracked" 的 界面 ， 显 示 了 本 地 
新 增 〈 尚 不 在 版 本 库 中 ) 的 文件 列表 ， 而 且 提 示 符 也 变 了 ， 由 "What 
now>" 变 为 "Add untracked> >"。 依 次 输入 1、3、6 将 产 代码 添加 到 版 
Ee 


输入 “1”: 


Add untracked> >1 
*1:src/Makefile 
2:src/hello 
3:src/main.c 
4:src/main.o 
5:src/version.h 
6:src/version.h.in 


输入 “3”: 


Add untracked> >3 
*1:src/Makefile 
2:src/hello 
*3:src/main.c 
4:src/main.o 
5:src/version.h 


6:src/version.h.in 


输入 “6”: 


Add untracked> >6 
*1:src/Makefile 
2:src/hello 
*3:src/main.c 
4:src/main.o 
5:src/version.h 
*6:src/version.h.in 
Add untracked>> 


每 次 输入 文件 序号 ， 对 应 的 文件 前 面 都 添加 一 个 星 号 ， 代 表 将 此 
文件 添加 到 和 暂 存 区 。 在 提示 符 "Add untracked > > "处 按 回 车 键 ， 完 成 
文件 添加 ， 返 回 主 界面 。 


Add untracked> > 

added 3 paths 

***CommandSs*** 

1:Status 2:update 3:revert 4:add untracked 
5:patch 6:diff 7:quit 8:help 

What now> 


此 时 输入 “1” 碍 看 状态 ， 可 以 看 到 三 个 文件 添加 到 暂 存 区 中 。 


What now>1 

staged unstaged path 

1:+20/-0 nothing src/Makefile 

2:+10/-0 nothing src/main.c 

3:+6/-0 nothing src/version.h.in 
***CommandSs*** 

1:Status 2:update 3:revert 4:add untracked 
5:patch 6:diff 7:quit 8:help 


输入 “7” 退 出 交互 界面 。 


查看 文件 状态 ， 可 以 发 现 三 个 文件 被 添加 到 暂 存 区 中 。 


$git status-s 

A src/Makefile 

A src/main.c 

A src/version.h.in 
?7 src/hello 

?7 src/main.o 

?3? src/version.h 


完成 提交 。 


$git commit-m "Hello world initialized." 
[master d7ice92]Hello world initialized. 

3 files changed,36 insertions(+),0©0 deletions(-) 
create mode 100644 src/Makefile 

create mode 100644 src/main.c 

create mode 100644 src/version.h.in 


10.7 ”Hello World3| 发 的 新 问题 


到 src 目 了 永 中 ， 对 Hello World 执 行 编译 。 


$cd/path/to/my/workspace/demo/src 
$make clean&&make 

rm-f hello main.o version.h 
version.h.in=>version.h 

cc-Cc-o main.o main.c 

cCc-o hello main.o 


运行 编译 后 的 程序 ， 是 不 是 对 版 本 输出 不 满意 呢 ? 


$./hello 
Hello,world. 
version:old_practice-4-gd71ice92. 


之 所 以 显示 长 长 的 版 本 号 ， 是 因为 使 用 了 在 本 章 最 开始 留 
的 “ 影 "。 现 在 为 Hello world 留 下 一 个 新 的 “ 影 ” (一 个 新 的 里 程 碑 ) 
吧 。 


$git tag-m "Set tag hello 1.0." hello 1.0 


然后 清除 上 次 编译 结果 后 ， 重 新 编译 和 运行 ， 可 以 看 到 新 的 输 


$make clean&&make 
rm-f hello main.o version.h 


version.h.in=>version.h 
cCc-Cc-o main.o main.c 
cCc-o hello main.o 
$./hello 

Hello,world. 
version:hello 1.0. 


还 不 错 ， 显 示 了 新 的 版 本 号 。 此 时 在 工作 区 查看 状态 ， 会 发 现 工 
作 区 “不 干净 ”。 


$git status 

#0n branch master 

#Untracked files: 

#(uUse "git add<file>..."to include in what will be committed) 


## 

#hello 
#main.o 
#version.h 


编译 的 目标 文件 和 从 模板 生成 的 头 文 件 出 现在 了 Git 的 状态 输出 
中 ， 这 些 文件 会 对 以 后 的 工作 造成 干扰 。 当 写 了 新 的 源 代码 文件 需要 
深 加 到 版 本 库 中 时 ， 因 为 这 些 干扰 文件 的 存在 ， 不 得 不 逐一 挑 迁 要 添 
加 的 文件 。 更 为 严重 的 是 ， 如 有 果 不 小 心 执 行 git add. 或 git add-A 命 令 会 
将 编译 的 目标 文件 及 其 他 临时 文件 加 入 版 本 库 中 ， 当 费 存储 空间 不 


说 ， 甚 至 还 会 造成 冲突 。 


Git 提 供 了 文件 忽略 功能 ， 可 以 用 来 解决 这 个 问题 。 


10.8 文件 忽略 


Git 提 供 了 文件 忽略 功能 。 当 对 工作 区 某 个 目录 或 某 些 文件 设置 了 
忽略 后 ， 再 执行 git status 碍 看 状态 时 ， 被 忽略 的 文件 即使 存在 也 不 会 
显示 为 未 跟踪 状态 ， 甚 至 根本 感觉 不 到 这 些 文 件 的 存在 。 现 在 就 针对 
Hello world 程 序 目 隶 试验 一 下 。 


$cd/path/to/my/workspace/demo/src 
$git status-s 

?3?3 hello 

7? main.o 

7? version.h 


可 以 看 到 src 目 录 下 编译 的 目标 文件 等 显示 为 未 跟踪 ， 每 一 行 开头 
的 两 个 问号 好 像 在 向 我 们 请 求 :“ 快 把 我 们 添加 到 版 本 库 里 吧 *。 


执行 下 面 的 命令 可 以 在 这 个 目录 下 创建 一 个 名 为 .gitignore 的 文件 
(注意 文件 的 前 面 有 个 点 ) ， 把 这 些 要 忽略 的 文件 写 在 其 中 ， 文 件 名 
可 以 使 用 通配符 。 注 意 ; 第 2 行 到 第 5 行 开头 的 右 尖 括号 是 cat 命 令 的 提 
示 符 ， 不 是 用 户 的 输入 。 


$cat> .gitignore<<EOF 
>hello 

> 0 

>*.h 

>EOF 


看 看 写 好 的 .gitignore 文 件 。 每 个 要 忽略 的 文件 显示 在 一 行 。 


$cat .gitignore 
hello 

* ,0 

* ,hh 


再 来 看 看 当前 工作 区 的 状态 。 


$git status-s 
?2? ,gitignore 


把 .gitignore 文 件 添加 到 版 本 库 中 吧 。 (如 果 不 希 望 添 加 到 库 里 ， 
也 不 希望 .gitignore 文 件 带 来 干扰 ， 可 以 在 忽略 文件 中 忽略 自己 。) 
$git add.gitignore 
$git commit-m "ignore object files." 
[master b3af728]ignore object files. 


1 files changed,3 insertions(+),0 deletions(-) 
create mode 100644 src/.gitignore 


1. 文 件 .gitignore 可 以 放 在 任何 目录 中 


文件 .gitignore 的 作用 范围 是 其 所 处 的 目录 及 其 子 目 录 ， 因 此 如 果 
把 刚刚 创建 的 .gitignore 移 动 到 上 一 层 目 录 ( 仍 位 于 工作 区 内 ) 也 应 该 
有 效 ， 移 动 操作 如 下 : 
$git mv.gitignore.. 
$git status 


#0n branch master 
#Changes to be committed: 


#(USe "git reset HEAD<file>..."to unstage) 
# 

#renamed: .gitignore->../.gitignore 

# 


果然 移动 .gitignore 文 件 到 上 层 目 录 ，Hello world 程 序 目 录 下 的 目 
标 文 件 依然 被 忽略 着 。 执 行 提交 : 
$git commit-m "move.gitignore outside also works." 
[master 3488f2c]move.gitignore outside also works. 


1 files changed,0 insertions(+),0 deletions(-) 
rename src/.gitignore=> .gitignore(100%) 


2. 忽 上 略 文 件 有 错误 ， 后 果 很 严重 


实际 上 ， 上 面 写 的 名 略 文件 不 是 非常 好 ， 为 了 忽略 version.h， 结 
林 使 用 了 通配符 *.h 会 把 源码 目 孙 下 的 有 用 的 头 文件 也 给 忽略 掉 ， 导 致 
应 该 添加 到 版 本 库 的 文件 起 记 添 加 。 


在 当前 目录 下 创建 一 个 新 的 头 文件 helloh。 


$echo "/*test*/">hello.h 


在 工作 区 状态 显示 中 看 不 到 hello.h 文 件 。 


$git status 
#0n branch master 
nothing to commit(working directory clean) 


只 有 使 用 了 --ignored 参 数 ， 才 会 在 状态 显示 中 看 到 被 忽略 的 文 


件 。 
$git status--ignored-s 
1! hello 
1! hello.h 
1! main.o 
11 version.h 


要 添加 hello.h 文 件 ， 使 用 git add-A 和 git add. 都 失效 。 无 法 用 这 两 
个 命令 将 hello.h 添 加 到 暂 存 区 中 。 
$git add-A 


$git add. 
$git status-s 


只 有 在 添加 操作 的 命令 行 中 明确 地 写 入 文件 名 ， 并 且 提 供 -f 参 数 
才能 真正 添加 。 
$git add-f hello.h 
$git commit-m "add hello.h" 
[master 48456abl]add hello.h 


1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 src/hello.h 


3. 忽 上 略 只 对 未 跟踪 文件 有 效 ， 对 于 已 加 入 版 本 库 的 文件 无 效 


文件 hello.h 添 加 到 版 本 库 后 ， 束 不 再 受到 .gitignore 设 置 的 文件 名 
略 所 影响 了 ， 对 helloh 的 修改 都 会 立刻 被 跟 踩 到 。 这 是 因为 Git 的 文件 
忽略 只 是 对 未 入 库 的 文件 起 作用 。 


$echo "/*end*/">>hello.h 
$git status 

#0n branch master 
#Changed but not updated: 


#(USe "git add<file>..." to update what will be committed) 
#(USe "git checkout--<file>..." to discard changes in working 
directory) 


#modified:hello.h 
# 
no changes added to commit(use "git add" and/or "git commit-a") 


偷懒 式 提 交 。 (使 用 了 -a 参数 提交 ， 不 用 预 完 执行 git add 命 令 。) 


站 


$git commit-a-m" 偷懒 了 , 直接 用 -a 参数 直接 提交 。 
[master 613486c] 偷 懒 了 ,直接 用 -a 参数 直接 提交 。 
1 files changed,1 insertions(+), 0 deletions(-) 


:UD 


4. 本 地 独 至 式 忽略 文件 


文件 .gitignore 设 置 的 文件 忽略 是 共 至 式 的 。 之 所 以 称 其 为 “ 共 至 
式 ”， 是 因为 .gitignore 被 添加 a 到 版 本 库 后 成 为 了 版 本 库 的 一 部 分 ， 当 版 
本 库 共享 给 他 人 (克隆 ) ， 或 者 把 版 本 库 推送 (PUSH) 到 集中 式 的 
服务 器 (或 他 人 的 版 本 库 ) 时 ， 这 个 忽略 文件 就 会 出 现在 他 人 的 工作 
区 中 ， 文 件 忽略 在 他 人 的 工作 区 中 同样 生效 。 


与 “ 共 圣 式 ” 忽 上 略 对 应 的 钙 “ 独 译 式 ”忽略 。 独 至 式 忽略 束 是 不 会 因 
为 版 本 库 共 至 ， 或 者 版 本 库 之 间 的 推送 传递 给 他 人 的 文件 忽略 。 独 至 
式 忽 略 有 两 种 方式 : 


一 种 是 针对 具体 版 本 库 的 “ 独 享 式 ” 忽 上 略 。 即 在 版 本 库 .git 目 永 下 的 
一 个 文件 .giUinfo/exclude 来 设置 文件 名 略 。 


另外 一 种 是 全 局 的 “ 独 侍 式 ” 忽 上 略 。 即 通过 Git 的 配置 变量 
core.eXcludesfile 指 定 的 一 个 名 略 文件 ， 其 设置 的 忽略 对 所 有 本 地 版 本 
库 均 有 效 。 


至 于 哪些 情况 需要 通过 同 版 本 库 中 提交 .gitignore 文 件 设置 共 译 式 
的 文件 忽略 ， 哪 些 情 况 通 过 .gitinfo/exclude 设 置 只 对 本 地 有 效 的 独 享 
式 文件 忽略 ， 这 取决 于 要 设置 的 文件 忽略 是 否 具 有 普 遇 意义 。 如 采 文 
件 忽略 对 于 所 有 使 用 此 版 本 库 工 作 的 人 都 有 花 ， 束 通过 在 版 本 库 相 应 
的 目录 下 创建 一 个 .gitignore 文 件 建立 名 略 ;， 和 否则， 如果 十 需要 忽略 工 
作 区 中 创建 的 一 个 试验 目录 或 试验 性 的 文件 ， 则 使 用 本 地 忽略 。 


例如 ， 我 的 本 地 就 设置 着 一 个 全 局 的 独 享 的 文件 忽略 列表 (这 个 
文件 名 可 以 随意 设置 ) : 


$git config--global core.excludesfile/home/jiangxin/.gitignore 
$git config core.excludesfile 

/home/jiangxin/ .gitignore 

$cat/home/jiangxin/ .gitignore 

* 一 #Viml 临 时 文件 
* .pyc#python 的 编译 文件 
.* ,mmx# 不 是 正则 表达 式 哦 ,因为 FreeMind- MMX 的 辅助 文件 以 点 开头 


5.Git 忽 略语 法 


关于 Git 的 忽略 文件 的 语法 规则 再 多 说 几 句 : 
忽略 文件 中 的 空 行 或 以 井 号 (#) 开始 的 行 会 被 忽略 。 


可 以 使 用 通配符 ， 参见 Linux 手 册 : glob (7) 。 例 如 : 星 号 (*) 
代表 任意 多 字符 ， 问 号 (? ) 代表 一 个 字符 ， 方 括号 ([abc]) 代表 可 
选 字符 范围 等 。 


如 果 名 称 的 最 前 面 是 一 个 路 径 分 隔 符 (/) ， 表 明 要 名 略 的 文件 在 
此 目录 下 ， 而 非 子 目录 的 文件 。 


如 果 名 称 的 最 后 面 是 一 个 路 径 分 隔 符 (/) ， 表 明 要 名 略 的 是 整个 
目 永 ， 同 名 文件 不 忽略 ， 人 否则 同名 的 文件 和 目录 都 忽略 。 


通过 在 名 称 的 最 前 面 添加 一 个 感叹 号 (! ) ， 代 表 不 忽略 。 


下 面 的 文件 名 略 示 例 ， 包 含 了 上 壕 要 后 : 


# 这 是 注释 行 - -被 忽略 

* .a # 忽略 所 有 以 .a 为 扩展 名 的 文件 。 

11ib.a # 但 是 1ib .a 文件 或 目录 不 要 忽略 , 即使 前 面 设置 了 对 * .a 的 忽略 。 

/TODO # 只 忽略 此 目录 下 的 TODO 文 件 , 子 目录 的 TODO 文 件 不 忽略 。 

build/ # 忽略 所 有 build/ 目 录 下 的 文件 。 

doc/* ,txt # 忽略 文件 如 doc/notes .txt, 但 是 文件 如 doc/server/arch.txt 不 
被 忽略 。 


10.9 文件 归档 


如 果 使 用 压缩 工具 (tar、7zip、winzip、rar 等 ) 将 工作 区 文件 归 
档 ， 一 不 小 心 会 把 版 本 库 (.git 目 录 ) 包含 其 中 ， 其 至 将 工作 区 中 的 忽 
上 略 文件 、 临 时 文件 也 包含 其 中 。Git 提 供 了 一 个 归档 命令 git archive， 
可 以 对 任意 提交 对 应 的 目录 树 建 立 归 档 。 示 例如 下 : 


基于 最 新 提交 建立 归档 文件 latest.zip 。 


$git archive-o latest.zip HEAD 


只 将 目录 src 和 doc 建 立 到 归档 partial.tar 中 。 


$git archive-o partial.tar HEAD src doc 


基于 里 程 碑 v1.0 建 立 归 档 ， 并 且 为 归档 中 的 文件 添加 目录 前 级 
1.0。 


$git archive--format=tar--prefix=1.0/v1i.0|gzip>fo0-1.0.tar.gz 


在 建立 归档 时 ， 如 果 使 用 树 对 象 ID 进 行 归档 ， 则 使 用 当前 时 间作 
为 归档 中 文件 的 修改 时 间 ， 而 如 条 使 用 提交 ID 或 里 程 碑 等 ， 则 使 用 提 
交 建 立 的 时 间作 为 归档 中 文件 的 修改 时 间 。 


如 果 使 用 tar 格 式 建 立 归 档 ， 并 且 使 用 提交 ID 或 里 程 碑 ID ， 还 会 把 
提交 ID 记录 在 归档 文件 的 文件 关中。 记录 在 文件 头 中 的 提交 ID 可 以 通 


过 git tar-commit-id 命 令 获 取 。 


如 果 希 望 在 建立 归档 时 名 上 略 某 些 文件 或 目录 ， 可 以 通过 为 相应 文 
件 或 目录 建立 export-ignore 属 性 加 以 实现 。 具 体 参 见 本 书 第 8 篇 第 41 
划 “41.1 属 性 ”一 入 。 


第 11 章 ”历史 军权 


经 过 了 之 前 众多 的 实践 ， 版 本 库 中 已 经 积累 了 很 多 次 提交 了 ， 从 
下 面 的 命令 中 可 以 看 出 有 14 次 提交 。 


$git rev-list HEAD|wc-1 
14 


有 很 多 工具 可 以 研究 和 分 析 Git 的 历史 提交 ， 在 前 面 的 实践 中 ， 我 
们 已 经 多 次 用 到 相关 的 Git 命 令 碍 看 历史 提交 、 查 看 文件 的 历史 版 本 、 
进行 差异 比较 等 。 本 章 除 了 对 之 前 用 到 的 相关 Git 命 令 作 一 下 尽 结 外 ， 
还 要 再 介绍 几 球 图 形 化 的 客户 端 。 


11.1 图 形 工 具 : gitk 


gik 是 最 早 实现 的 一 个 图 形 化 的 Git 版 本 库 浏 览 器 软件 ， 基 于 Tcl/Tk 
实现 ， 因 此 gitk 非 常 简洁 ， 本 身 就 是 由 一 个 1 万 多 行 的 td 脚本 写成 的 。 
gitk 的 代码 已 经 和 Git 的 代码 放 在 了 同一 个 版 本 库 中 ，gitk 随 Git 一 同 发 
布 ， 不 用 特别 地 安装 即 可 运行 。gitk 可 以 显示 提交 的 分 支 图 ， 可 以 显 
示 提交 、 文 件 、 版 本 间 的 差异 等 。 


在 版 本 库 中 调用 gitk， 束 会 浏览 该 版 本 库 ， 显 示 其 提交 的 分 文 
" gitk 可 以 像 命令 行 工 具 一 样 使 用 不 同 的 参数 进行 调用 。 


显示 所 有 的 分 支 。 
$gitk--all 
显示 2 周 以 来 的 所 有 提交 。 


$gitk--since="2 weeks ago" 


显示 某 个 里 程 碑 (v2.6.12) 以 来 ， 针 对 某 些 目录 和 文件 
(include/scsi 目 录 和 drivers/scsi 目 录 ) 的 提交 。 


$gitk v2.6.12..include/scsi drivers/scsi 
图 11-1 束 是 在 DEMO 版 本 库 中 运行 gitk--all 的 显示 。 
从 图 11-1 中 可 见 不 同 颜色 和 形状 区 分 的 引用 : 
绿色 的 master 分 文 。 
黄色 的 hello_1.0 和 old_practice 里 程 碑 。 


灰色 的 stash 。 


gitk 使 用 TcW/Tk 开 发 ， 在 显示 上 没有 系统 中 原生 图 形 应 用 那么 漂 腕 
的 界面 ， 长 至 可 以 用 


丑陋 来 形容 。gitk 只 能 用 于 版 本 库 浏 览 ， 如 果 要 使 用 TeVTK 图 形 界面 进行 提交 则 需要 使 用 另 
外 的 命令 : git gui (或 git citool) 命令 ,不 过 下 面 将 要 介绍 的 gitg 和 qsit 在 易 用 性 
上 比 gitk 及 git gui 进步 了 不 少 . 


Jiarg Xin dargurBossxpcomy oo1207484339 
Jiarg Wn danguin®ossxp com> 
er we diargdnrGossxpcomr 


Sd 


和 5 7010-17-0T 1 人， 
ttars Jiang Ein *Jiongxinformxp.com? 2010"12"08 093166:35 
hello 1.0 


ENDME 3 from 
go objet # 


11-1 gitk 查看 DEMO 版 本 库 


11.2 图 形 工 具 : gitg 


gitg 是 使 用 GTK+ 图 形 库 实现 的 一 个 Git 版 本 库 浏览 器 软件 。Linux 下 最 著名 的 Gnome 
桌面 环境 使 用 的 就 是 GTK+， 因 此 在 Linux 下 gitg 有 着 非常 漂亮 的 原生 的 图 形 界面 。gitg 不 
但 能 够 实现 gitk 的 全 部 功能 ， 即 浏览 提交 历史 和 文件 ， 还 能 帮助 执行 提交 。 

在 Linux 上 安装 gitg 很 简单 ， 例 如 在 Debian 或 Ubuntu 上 ， 直 接 运 行 下 面 的 命令 就 可 以 
进行 安装 。 

s sudo aptitude install gitg 

安装 完毕 后 就 可 以 在 可 执行 路 径 中 找到 gitg。 


$s which gitg 
/usr/bin/gqitq 


为 了 演示 gitg 具备 提交 功能 ， 先 在 工作 区 做 出 一 些 修改 。 
C1)》 删除 没有 用 到 的 helloe-nh 文件 。 


s cd /path/to/my/workspace/demo 
s§ rm src/hello.h 


(2) 在 REANMF 文件 后 面 筷 加 一 行 。 


SS echo "Wait..." >> README 


(3) 查看 当前 工作 区 的 状态 。 
S git status ~s 

M README 

D src/helilo.h 


现在 可 以 在 工作 区 下 执行 gitg 命令 。 
SS gitg & 


图 11-2 就 是 gitg 的 默认 界面 ， 显 示 了 提交 分 支 图 以 及 选中 提交 的 提交 信息 和 变更 文 
件 列表 等 。 


站 Pg -Hero (master] 


on WIP on master’ 2bJ1c]9 Merge cormmt scr2f05 
© erstees) tmstaged changes 

人 从 协 了 ,直接 月 -4 参数 外 接 提 六 ， 

addheioh 

movwe gligere oulSde also works 

ignnre nhjeet Win 


README is om welcome tx 

restore file” welcome be 

Solore trash es, (sng: gt dd -u) 

Me ratgce | Mer9e commt acs2105 
WP commit in detached HEAD made 


oetws 上 
SHA: dice5255b3b08c7T1591De4s31760399dd6da24 寺 
Authar: jang Xn 
acer 2010 秆 12 月 07 月 至 期 二 128133 涩 45 移 
subject: Helio world initialized. 


2010 侍 12 月 907 日 大 项 二 11 时 S 半 
2010 平 12 月 5 号 山 抽 14 时 2 
2010 年 12 月 907 月 中 期 二 19 时 4 
2010 科 12 月 07 电 人 期 二 19 时 殉 
2010 币 12 月 07 甩 性 由 二 19 时 34 
2Dn1n 征 17 月 57 月 是 划一 1081 7 


2010 革 12 月 67 惠 性 期 二 14M50 
2010 年 12 月 07 日 省 其 二 44 时 22 
2010 咎 12 月 07 日 下 期 14H02 
2010 年 12 月 05 日 是 期 日 15815】 


2010 放 12 月 05 日 是 期 日 15 时 43 


图 11-2 gitg 查看 DEMO 版 本 庄 


从 图 11-2 中 可 以 看 见 用 不 同 寡 色 的 标签 显示 的 状态 标识 包括 引用 )，: 
口 栖 色 的 master 分 支 。 

口 黄色 的 hello 1.0 和 old practice 里 程 碑 . 

口 粉色 的 stash 标签 . 

口 白色 的 显示 工作 区 非 暂 存 状 态 的 标签 : 


点 击 gitg 下 方 窗 口 的 标签 “tree”， 会 显示 此 提交 的 目录 树 ， 如 图 11-3 所 示 。 


|@ (Caprese) marse cemma “acciey jang xin 2010 和 12 朋 05 基期 日 15 时 5 
| mmt nn detached EAD rrode BIN 2010 和 P12 月 05 有 全 凑 淹 月 13943 


图 11-3 gitg 查看 目录 树 
提交 功能 是 gitg 的 一 大 特色 。 点 击 gitg 顶部 窗口 的 commit 标签 ， 显 示 如 图 11-4 的 界面 。 


图 11-4 ”gitg 的 提交 界面 


图 11-4 中， 左下 方 窗口 显示 的 是 未 更 新 到 暂 存 区 的 本 地 改动 。 鼠 标 右 击 ， 在 弹出 菜单 
中 选择 “Stage”， 如 图 11-5 所 示 - 


1 1 Helio, 
2 TMice te meet you. 


图 11-5 ”gitg 提交 界面 中 的 弹出 菜单 


当 把 文件 RRanMF 添加 到 暂 存 区 后 ， 可 以 看 到 RRADMR 文件 出 现在 右 下 方 的 窗口 中 ， 如 
图 11-6 所 示 ， 


图 11-6 ”gitg 提交 文件 加 入 暂 存 区 


此 时 如 果 回 到 提交 历史 查看 界面 ， 可 以 看 到 在 “stash” 标 签 的 下 方 ， 同 时 出 现 了 
“staged” 和 “unstaged” 两 个 标签 分 别 表示 和 暂 存 区 和 工作 区 的 状态 ， 如 图 11-7 所 示 。 


Due 
20104 1]2767 日 一 MMS 


2010 征 12 月 50 月 星 草 二 243433 
2930 年 2 月 67 日 星期二 19M43 


图 11-7 gitg 界面 中 的 staged 和 unstaged 村 : 签 


当 通 过 gitg 的 界面 选择 好 要 提交 的 文件 (加 入 暂 存 区 ) 之后， 执行 提交 ， 如 图 11-8 所 示 。 

图 11-8 的 提交 说 明 对 话 框 的 下 方 有 两 个 选项 ， 当 选择 了 “Add signed-off-by” 选 项 后 ， 
在 提交 日 志 中 会 自动 增加 相应 的 说 明文 字 。 图 11-9 可 以 看 到 刚刚 的 提交 已 经 显示 在 提交 历史 
的 最 顶端 ， 在 提交 说 明 中 出 现 了 Signed-off-by 文字 说 明 ， 

gitg 还 是 一 个 比较 新 的 项 目 ， 在 本 文 撰写 的 时 候 ，gitg 才 是 0.0.6 版 本 ， 相 比 下 面 要 介 
绍 的 qgit 还 缺乏 很 多 功能 。 例 如 gitg 没有 文件 的 blame〈 追 溯 ) 界面 ， 也 不 能 直接 将 文件 检 
出 ， 但 是 gitg 整体 的 界面 风格 ， 以 及 易 用 的 提交 界面 给 人 的 印象 非常 识 刻 ， 


0 Geino (Ouster] 


试 才 全 月 49 这 条 入 交 ， 


Wty - domoe (mnster] 


信物 了 六 梁 用 -5 多 条 让 潜 提 交 , 


En | 

SHAI <a23a195427df30d59dct1821ef21379dic2r17m 
sthor: jnvg Wn 
Dnte; 2019 和 P12 月 08 月 着 芽 三 15952 分 9 从 


图 11-9 ”gitg 显示 的 最 新 提交 


11.3 图 形 工 具 : qgit 


前 面 介绍 的 gitg 是 基于 GTK+ 这 一 Linux 标准 的 图 形 库 ， 那 么 也 许 有 读者 已 经 猜 到 
qgit 是 使 用 Linux 另外 一 个 著名 的 图 形 库 QT 实现 的 。QT 的 知名 产 不 亚 于 GTK+， 是 著名 的 
KDE 桌面 环 弹 用 到 的 图 形 库 ， 也 是 著 势 待 发 准备 和 Android 一 较 高 低 的 MeeGo 的 UI 核心 。 
qgit 目前 的 版 本 是 2.3， 相 比 前 面 介绍 的 gitg ， 其 经 历 的 开发 周期 要 长 了 不 少 ， 因 此 也 提供 
了 更 多 的 功能 . 

在 Linux 上 安装 qgit 很 简单 ， 例 如 在 Debian 或 Ubuntu 上 ， 直 接 运 行 下 面 的 命令 就 可 以 
进行 安装 。 


§ sudo aptitude install qgit 


安装 完毕 就 可 以 在 可 执行 路 径 中 找到 qgit。 

$s which qgit 

/usr/bin/aqqit 

qgit 和 gitg 一 样 不 但 能 够 浏览 提交 历史 和 文件 ， 还 能 帮助 执行 提交 。 为 了 调试 提交 ， 将 
回 滚 在 上 一 节 所 做 的 操 交 .。 

口 使 用 重 置 命令 回 滚 最 后 一 次 提交 。 


8 git reset HEAD’ 
Unstaged changes after reaet: 


M README 
NM src/helio.h 
口 查看 当前 工作 区 的 状态 ， 


$ git status 

# On branch maaster 

# Changed but not updated: 

luse "git add/rm <file>..." to update what will be committed, 

(use "git checkout -- <files..." to discard changes in working directory, 


modified: README 


# 
# 
莫 
非 
提 deleted: src/hello.h 
# 


no changes added to commit {use qit add'" and/or "qit commit -an 


现在 可 以 在 工作 区 下 执行 qgit 命令 。 


SS qgit & 


启动 qgit ， 首 先 弹 出 一 全 对 话 框 ， 提 示 对 显示 的 提交 范围 和 分 支 范围 进行 选择 ， 如 钨 
11-10 所 未 ， 


图 11-10 qgit 启动 对 话 框 


对 所 有 的 选择 打 钓 ， 显 示 下 面 的 qgit 的 默认 界面 。 其 中 包括 了 提交 分 支 图 ， 以 及 选中 提 
交 的 提交 信息 和 变更 文件 列表 等 ， 如 图 11-11 所 示 : 


图 HH-I gqgit 主 界面 


从 图 11-11 中 可 以 看 见 用 不 同 颜 色 的 标签 显示 的 状态 标识 〈 包 括 引用 ) : 

口 绿色 的 master 分 支 。 

口 黄色 的 hello 1.0 和 old practice 里 程 碑 。 

口 灰 色 的 stash 标签 ， 显示 了 创建 时 候 的 位 置 ， 并 将 其 包含 的 针对 暂 存 区 状态 的 提交 也 
显示 了 出 来 。 

口 基 顶 端 显 示 一 行 绿色 背景 的 文字 : 工作 区 有 改动 。 


qgit 的 右键 菜单 非常 丰富 ， 图 11-11 显示 了 鼠标 右 击 提交 时 显示 的 弹出 菜单 ， 可 以 创建 ， 
切换 标签 或 分 支 ， 可 以 将 提交 导出 为 补丁 文件 。 


图 11-12 qgit 检 出 和 查看 文件 界面 


要 想 显 示 目 录 树 ， 键 人 大 写字 母 T ， 或 者 单 击 工 具 条 上 的 图 标 加 ， 就 会 在 左 侧 显 示 目 录 
树 窗口 ， 如 图 11-13 所 示 ， 

图 11-13 中 也 显示 了 目录 树 中 弹出 的 右键 菜单 。 当 选择 查看 一 个 文件 时 ， 会 显示 此 文件 的 
追 滴 ， 即 显示 每 一 行 是 在 哪个 版 本 由 谁 修 改 的 。 追 漳 窗 口 见 图 11-14 右 下 方 的 窗口 。 

qgit 也 可 以 执行 提交 。 选 中 qgit 顶部 窗口 最 上 一 行 “Working dir changes"， 蕊 标 右 击 ， 
显示 的 弹出 菜单 包含 了 “Commit…” 选 项 ， 如 图 11-15 所 示 。 


$F IIRORT Blot WoldNdaty| 


NEAOME 上 Worm wetcorme Esl 
restore fe wecome bt 
Ps dd 0) 


WA om Malte 2031ct9 Merge Commrt cc2169 
er IIcL9 Merge CE 30c2%0 
Commt cr2069 


README 


my/workspace/dermo 


ypdmed 
4 tuse “gt adarm Ney “bd what wh be commeited) 
上 《Use "gt checkout 、 <Se>.." to dscard changesin workng 
rectory) 


图 11-15 从 gqgit 弹 出 菜单 选择 提交 


点 击 弹出 菜单 中 的 “Commit,…”， 显 示 如 图 11-16 所 示 的 对 话 框 : 


Commit changes 


Index status 
README Not updated in ndex 
src/hello hn Not updated in ingex 


On branch master 
Changed but not updated: 
(use "git add/rm <file>,,.”" to update what will be committed) 
(vse "git checkout -一 <file>..,." to discard changes in working directory) 


we 


图 11-16 qgit 提交 界面 


如 图 11-16 所 示 ， 自 动 选中 了 所 有 的 文件 。 上 方 窗口 的 选中 文件 目前 的 状态 是 “Not 
updated in index”"”， 也 就 是 说 尚未 添加 到 暂 存 区 。 


使 用 qgit 做 提交 ， 只 要 选择 好 要 提交 的 文件 列表 ， 即 使 未 添加 到 暂 存 区 ， 也 可 以 直接 提 
交 。 在 下 方 的 提交 窗口 中 写 人 提交 日 志 ， 点 击 “Commit” 按 钮 开始 提交 ， 如 图 11-17 所 示 。 


Commit changes 
Index status 
™ README Not updated in ingex 
~ sromelon Not updated in NGex 


On branch master 

Changed but not vpdated 

(use "git add/rm <file>. -” to update what will be committed) 

(vse "git checkout 一 <file>. "+*" to discard changes in working directory) 


modified: README 


11-17 qgit 中 编辑 提交 说 明 


提交 完毕 返回 qgit 主 界面 ， 在 显示 的 提交 列表 的 最 上 方 ， 原 来 显示 的 “Working dir 
changes” 已 经 更 新 为 “Nothing to commit”， 并 且 可 以 看 到 刚刚 的 提交 已 经 显示 在 提交 历史 
的 最 顶端 ， 如 图 11-18 所 示 . 


Se 


图 11-18 qgit 中 显示 的 最 新 提交 


11.4 


人 和 全. 人 4 二 
命令 行 工 具 


上 面 介绍 的 几 款 图 形 界面 的 Git 版 本 库 浏览 器 最 大 的 特色 就 是 更 好 看 的 提交 关系 图 ， 还 
能 非常 方便 地 浏览 历史 提交 的 目录 树 ， 并 从 历史 提交 的 目录 树 中 提取 文件 等 ， 这 些 操作 对 于 
Git 命令 行 同样 可 以 完成 。 使 用 Git 命令 行 探索 版 本 库 历史 对 于 您 来 说 并 不 新 鲜 ， 因 为 在 前 几 
章 的 实践 中 已 经 用 到 了 相关 命令 ， 展 示 了 对 历史 记录 的 操作 。 本 节 将 对 这 些 命令 的 部 分 要 点 
进行 强调 和 补充 ， 
前 面 历次 实践 的 提交 基本 上 是 线性 的 提交 ， 研 究 起 来 没有 挑战 性 。 为 了 能 够 更 加 接近 于 
实际 又 不 失 简 法， 我 构造 了 一 个 版 本 库 放 在 了 Github 上 。 可 以 通过 如 下 操作 在 本 地 克隆 这 个 
示例 版 本 座 。 


s cd /path/to/my/workspace/ 

$ git clone git://github.com/ossxp-com/gitdemo-commit-tree.git 
Cloning into gitdemo-commit-tree..,. 

remote; Counting obijects:; 63, done, 

remote: Compressing obiects: 100% 151/51}, done. 

remote; Total 63 {deltra 8}), reused 0 ldeita 0| 

Receiving obiects: 100% {63/63}, 65.95 KiB, done. 

Resolving deltas: 100% (8/8), done. 

SS cd gitdemo-commit-tree 


运行 gitg 命令 ， 显 示 其 提交 关系 图 ， 如 图 11-19 所 示 。 


是 不 是 有 点 “ 乱 花 渐 欲 迷人 有 眼 ” 的 感觉 。 如 果 把 提交 用 里 程 碑 标识 的 圆圈 来 代表 ， 


排列 就 会 看 到 下 面 的 更 为 直 白 的 提交 关系 图 ， 如 图 11-20 所 示 。 


稍 加 


四 Commit a: mergeB with C. 
© commr c 
加 Commit a: merge D wkthEandF 


Add Images for gg treeview. jiang Xin 2010 年 12 月 09 日 星期 四 
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jiang Xin 2010 和 车 12 月 09 日 是 由 四 
图 11-19 ”演示 版 本 库 的 提交 分 支 医 
(a) 


© © 


(9) (EE) (EY 


( (WW YOO 
图 11-20 ”简化 的 提交 分 支 图 


Git 的 大 部 分 命令 可 以 使 用 提交 版 本 作为 参数 (如, git qdiff <commit-id>)， 有 
的 命令 则 使 用 一 个 版 本 范围 作为 参数 (如 : git log <revi>. .<rev2>)。Git 的 操 交 有 
着 各 式 各 样 的 表示 法 ， 提 交 范 围 也 是 一 样 ， 下 面 就 通过 两 个 命令 qit rev-parse 和 9git 
rev-1ist 分 别 研究 一 下 Git 的 版 本 表示 法 和 版 本 范围 表示 法 : 


11.4.1 版 本 表示 法 : git rev-parse 


命令 git rev-parse 是 Git 的 一 个 底层 命令 ， 其 功能 非常 丰富 (或 者 说 杂乱 )， 很 多 
Git 脚本 或 工具 都 会 用 到 这 条 命令 。 

此 命令 的 部 分 应 用 在 “第 4 章 Git 初始 化 ”一 章 中 就 已 经 看 到 。 例 如 可 以 显示 Git 版 本 
庄 的 位 置 (--git-dir)， 当 前 工作 区 目录 的 深度 (--show-cdup)， 共 至 可 以 被 Git 无 关 
的 应 用 用 于 解析 命令 行 参数 (--parseopt )。 

此 命令 可 以 显示 当前 版 本 库 中 的 引用 ， 

口 显 示 分 支 。 

$ git rev-parse -~symbolic ~-~branches 


mAster 


口 显 示 里 程 碑 。 


$git rev-parse--symbolic--tags 


QHIOTMIOONODmWrI 


显示 定义 的 所 有 引用 。 


其 中 refs/remotes/ 目 录 下 的 引用 称 为 远程 分 支 〈 或 远程 引用 ) ， 在 
后 面 的 章节 会 予以 介绍 。 


$git rev-parse--symbolic--glob=refs/* 
refs/heads/master 
refs/remotes/origin/HEAD 
refs/remotes/origin/master 
refs/tags/A 

refs/tags/B 

refs/tags/CcC 

refs/tags/D 

refs/tags/E 

refs/tags/F 

refs/tags/G 

refs/tags/H 

refs/tags/I 

refs/tags/J 


命令 git rev-parse 的 另外 一 个 重要 功能 束 是 将 一 个 Git 对 象 表达 式 表 
示 为 对 应 的 SHA1 哈 希 值 。 针 对 本 和 开始 克隆 的 版 本 库 gitdemo-commit- 
tree， 做 如 下 操作 。 


(1) 显示 HEAD 对 应 的 SHA1 哈 希 值 。 


$git rev-parse HEAD 
6652a0dce6a5067732c00ef0a220810a7230655e 


(2) 命令 git describe 的 输出 也 可 以 解析 为 正确 的 SHA1 哈 希 值 。 


$git describe 

A-1-g6652a0d 

$git rev-parse A-1-g6652a0d 
6652a0dce6a5067732c00ef0a220810a7230655e 


(3) 可 以 同时 显示 多 个 表达 式 的 SHA1 哈 希 值 。 


下 面 的 操作 可 以 看 出 master 和 和 refs/heads/master 都 可 以 用 于 指 代 


master 分 支 


$git rev-parse master refs/heads/master 
6652a0dce6a5067732c00ef0a220810a7230655e 
6652a0dce6a5067732c00efg0a220810a7230655e 


(4) 可 以 用 喻 希 值 的 前 几 位 指 代 整个 哈 希 值 。 


$git rev-parse 6652 6652a0d 
6652a0dce6a5067732c00ef0a220810a7230655e 
6652a0dce6a5067732c00ef0a220810a7230655e 


(5) 里 程 碑 的 两 种 表示 法 均 指向 相同 的 对 象 。 


$git rev-parse A refs/tags/A 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 


c9b03a208288aebdbfe8d84aeb984952a16da3f2 


(6) 里程 碑 A 实 际 指向 的 是 一 个 Tag 对 象 而 非 提 交 ， 用 下 面 的 三 
个 表示 法 可 以 显示 提交 本 号 的 哈 希 值 而 非 里 程 碑 对 象 的 哈 硕 值 。 


还 有 ， 下 面 的 语法 也 可 以 直接 作用 于 轻 量 级 里 程 碑 《直接 指向 提 
交 的 里 程 碑 ) ， 或 者 作用 于 提交 本 号 。 

$git rev-parse A^{}A^0 A^{commit} 

81993234fc1i2a325d303eccea20f6fd629412712 


81993234fc12a325d303eccea20f6fd629412712 
81993234fc12a325d303eccea20f6fd629412712 


(7) A 的 第 一 个 父 提交 束 是 B 所 指向 的 提交 。 


回忆 之 前 的 介绍 ，“^” 操 作 符 代表 父 提交 。 当 一 个 提交 有 多 个 父 所 
交 时 ， 可 以 通过 在 符号 “ 心 后 面 跟 上 一 个 数字 表示 第 儿 个 父 提 
交 。"AN" 就 相当 于 "A^1"。 而 BA0 代 表 了 B 所 指向 的 一 个 Commit 对 和 象 
(因为 B 是 Tag 对 象 ) 。 


$git rev-parse A^A^1 BAO 

776c5c9da9dcbb7e463c061d965ea47e73853b6e 
776c5c9da9dcbb7e463c061d965ea47e73853b6e 
776c5c9da9dcbb7e463c061d965ea47e73853b6e 


(8) 更 为 复杂 的 表示 法 。 


连续 的 “^” 符 号 依次 沿 着 父 提交 进行 定位 至 某 一 祖先 提交 。“ 人 ”后 


面 的 数字 代表 该 提交 的 第 几 个 父 提 交 。 


$git rev-parse AAA3A2 FA2 J 人 ^{} 


3252fcce40949a4a622a1lac012cb120d6b340ac8 
3252fcce40949a4a622a1lac012cb120d6b340ac8 
3252fcce40949a4a622a1lac012cb120d6b340ac8 


(9) 记号 一 <n> 就 相当 于 连续 <n>> 个 


$git rev-parse A~3 AAAAGA0 


e80aa7481beda65ae00e35afc4bc4b171f9boebf 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 


付 可 “和 人?” oO 


(10) 显示 里 程 碑 A 对 应 的 目录 树 。 下 面 两 种 写法 都 可 以 。 


“S$ git rev-parse A^{tree} A: 
95abpdgeTdbi4cail3d5S548dGc20a4872950e8e08c0 
S95SabdgeTdbi4cail3dS548dc20a4872950e8e08c0 


(11) 显示 树 里 面 的 文件 ， 下 面 两 种 表示 法 均 可 ， 


(12) 暂 存 区 里 的 文件 和 HEAD 中 的 文件 相同 。 
$ git rev-parse :gitg.png HEAD:gitg.png 
fcS8966cccieSaf24c2c9746196550241bcOlcs0 


fcs8966ccecie5af24c2c9T746196550241bcolc5sn0 


(13) 还 可 以 通过 在 提交 日 志 中 查找 字 串 的 方式 显示 提交 。 


S git rev-parse :/"Commit A" 


81993234fci2a325d303eccea20f6fad629412712 


(14) 再 有 就 是 reflog 相关 的 语法 ， 参 见 “ 第 7 华 Git 重 置 ” 


S git rev-parse HEADG{O0} masteref0) 
6652a0dce6aS067732c00ef0a220810a723065Se 


66S52a0dce6aS067732c00ef0a220810a723065Se 


- 章 中 关于 reflog 的 介绍 ， 


11.4.2 有 版 本 范围 表示 法 : git rev-list 


有 的 Git 命令 使 用 一 个 版 本 范围 作为 参数 ， 命 令 git rev-list 可 以 帮助 研究 Git 的 各 种 版 
本 范围 的 语法 ， 


e680aa74 2ab52ad 6346365 3252fCc 


图 11-21 标记 了 提交 ID 的 分 支 图 


口 如 图 11-21 所 示 ， 一 个 提交 ID 实际 上 就 可 以 代表 一 个 版 本 列表 ， 含 义 是 该 版 本 开始 
的 所 有 有 历史 提交 


S git rev-list -~-~oneline A 


8199323 Commit A:merge B with C. 
Qcd7f2e commit C. 

776c5c9 Commit B:merge D with E and F 
beb30ca Commit F:merge I with J 
212efce Commit D:merge G with H 
634836c commit 
3252fcc commit 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


OO 工 mmQ HH 


两 个 或 多 个 版 本 ， 相 当 于 每 个 版 本 单独 使 用 时 指 代 的 列表 的 并 


集 。 


$git rev-list--oneline D F 
beb30ca Commit F:merge I with J 
212efce Commit D:merge G with H 


634836c commit I. 
3252fcc commit J. 
2ab52ad commit H. 
e80aa74 commit 6G. 


在 一 个 版 本 前 面 加 上 符号 (^) 含义 是 取 反 ， 即 排除 这 个 版 本 及 其 
历史 版 本 。 
$git rev-list--oneline^G D 


212efce Commit D:merge G with H 
2ab52ad commit H. 


和 上 面 等 价 的 “点 点 ”表示 法 。 使 用 两 个 点 连接 两 个 版 本 ， 如 
G..D， 就 相当 于 ^G D 。 
$git rev-list--oneline G..D 


212efce Commit D:merge G with H 
2ab52ad commit H. 


版 本 取 反 ， 参 数 的 顺序 不 重要 ， 但 是 “点 点 ”表示 法 前 后 的 版 本 顺 
序 很 重要 。 


oe ABC 


$git rev-list--oneline^B C 
Qcd7f2e commit C. 


OO 语法: CAB 


$git rev-list--oneline CAB 
Qcd7f2e commit C. 


OO 语法: B..C 相 当 于 AB C 


$git rev-list--oneline B..cC 


Ocd7f2e commit 


C. 


O 语 法: C..B 相 当 于 ^CB 


$git rev-list--oneline C..B 


776c5c9 Commit 
212efce Commit 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


B:merge D with E and F 
D:merge G with H 
Ex 


H. 
G. 


三 扩 表 示 法 的 含义 古 两 个 版 本 共同 能 够 访问 到 的 除外 。 如 B.…… 
将 B 和 C 共 同 能 够 访问 到 的 F、I、J 排 除 在 外 。 


$git rev-list--oneline B...cC 


Ocd7f2e commit 
776c5c9 Commit 
212efce Commit 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


CG: 

B:merge D with E and F 
D:merge G with H 

E. 


H. 
G. 


三 点 表示 法 ， 两 个 版 本 的 前 后 顺序 没有 关系 。 实 际 上 r1......r2 相 
当 于 rl r2--not$ (git merge-base--all rl r2) ， 所 以 和 顺序 无 关 。 


$git rev-list--oneline C...B 


Ocd7f2e commit 
776c5c9 Commit 
212efce Commit 
83be369 commit 


C. 

B:merge D with E and F 
D:merge G with H 

Ex 


2ab52ad commit H. 
e80aa74 commit 6G. 


某所 区 的 历史 提交 ， 目 身 除外 ， 用 语法 r1A@ 表 示 。 


$git rev-list--oneline BA@ 
beb30ca Commit F:merge I with J 
212efce Commit D:merge G with H 
634836c commit 工 ， 

3252fcc commit 
83be369 commit 
2ab52ad commit 
e80aa74 commit 


@ 工 站 号 


提交 本 喘 不 包括 其 历史 提交 ， 用 语法 r1I^! 表 示 。 


$git rev-list--oneline BA! 

776c5c9 Commit B:merge D with E and F 
$git rev-list--oneline F^!ID 

beb30ca Commit F:merge I with J 
212efce Commit D:merge G with H 
2ab52ad commit H. 


11.4.3” 浏 蜗 日 志 : gitlog 


命令 git log 古 老 朋 友 了， 在 前 面 的 草 市 中 曾经 大 量 地 出 现 ， 用 于 


命令 git log 的 后 面 可 以 接 表 示 版 本 范围 的 参数 ， 当 不 使 用 任何 表 
示 版 本 范围 的 参数 时 ， 相 当 于 使 用 了 默认 的 参数 HEAD， 即 显示 当前 
HEAD 能 够 访问 到 的 所 有 历史 提交 。 下 面 的 示例 使 用 了 前 面 介 绍 的 版 
本 范围 表示 法 : 

$git 1og--oneline FAID 

beb30ca Commit F:merge I with J 

212efce Commit D:merge G with H 


2ab52ad commit H. 
e80aa74 commit 6G. 


通过 --graph 参 数 调 用 git log 可 以 显示 字符 界面 的 提交 关系 图 ， 而 且 
不 同 的 分 文 还 可 以 用 不 同 的 颜色 来 表示 。 如 有 果 硕 望 每 次 得 看 日 志 的 时 
候 都 看 到 提交 关系 图 ， 可 以 设置 一 个 别名 ， 用 别名 来 调用 。 


$git config--global alias.glog "lo0g--graph" 


定义 别名 之 后 ， 每 次 布 望 目 动 显 示 提 交 关 系 图 ， 束 可 以 使 用 别名 


会 -人 
命令 : 


$git glog--oneline 

*6652a0d Add Images for git treeview. 
*8199323 Commit A:merge B with C. 

人 

|*ocd7f2e commit C. 


人 

*-,\776c5c9 Commit B:merge D with E and F 
I\\\ 

1117 

||1*beb30ca Commit F:merge I with J 

NN 

| 1 


|*3252fcc commit J， 

|1*634836c commit 工 . 

|*83be369 commit E. 

*212efce Commit D:merge G with H 
人 

|*2ab52ad commit H 

*e80aa74 commit G， 


3. 显 示 最 近 的 几 条 日 志 


可 以 使 用 参数 -<n> (<n> 为 数字 ) ， 显 示 最 近 的 <n> 条 日 


志 。 例 如 下 面 的 命令 显示 最 近 的 3 条 日 志 。 


$git 1l0g-3--pretty=oneline 

6652a0dce6a5067732c00ef0a220810a7230655e Add Images for git 
treeview. 

81993234fc12a325d303eccea20f6fd629412712 Commit A:merge B with 
C. 

Qcd7f2ea245d90d414e502467ac749f36aa32cc4 commit C. 


使 用 参数 -p 可 以 在 显示 日 志 的 时 候 同 时 显示 改动 。 


$git lo0g-p-1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Dec 9 16:07:11 2010+0800 

Add Images for git treeview. 
Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 
diff--git a/gitg.png b/gitg.png 

new file mode 100644 

index 0000000. .fc58966 

Binary files/dev/null and b/gitg.png differ 
diff--git a/treeview.png b/treeview.png 

new file mode 100644 

index 0000000. .a756d12 

Binary files/dev/null and b/treeview.png differ 


因为 是 二 进 制 文件 改动 ， 默认 不 显示 改动 的 内 容 。 实 际 上 Git 的 莽 
异 文件 提供 对 二 进 制 文件 的 支持 ， 本 书 第 7 篇 第 38 章 将 予以 专题 介绍 。 


使 用 -p 参 数 会 让 日 志 输 出 显得 非常 见 余 ， 当 不 需要 知道 具体 的 改 
动 而 只 想 知 道 改动 在 哪些 文件 上 时 ， 可 以 使 用 --stat 参 数 。 输 出 的 变更 
概要 像 极 了 GNU 的 diffstat 命 令 的 输出 。 


$git log--stat--oneline 工 ,.C 

Qcd7f2e commit C. 

README | 1+ 

doc/C.txt|1+ 

2 files changed,2 insertions(+),0 deletions(-) 
beb30ca Commit F:merge I with J 

3252fcc commit J. 

README | 7 十 十 十 十 十 十 十 

doc/J.txt|1+ 

src/.gitignore|3+++ 


SrCc/Makef1iJe | 27+ 二 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
SrCc/Vmain.c| 工 0++ 十 十 十 十 十 十 十 十 
src/version.h.in|6++++++ 

6 files changed,54 insertions(+),0© deletions(-) 


6. 定 制 输出 


Git 的 日 志 输 出 命令 提供 了 很 多 输出 模板 选择 ， 可 以 根据 需要 选择 


7 一 一 记 y 冰 坏人 全 二 
见 余 显示 或 精简 显示 。 


参数 --pretty=raw 显 示 commit 的 原始 数据 ， 可 以 显示 提交 对 应 的 树 


ID 。 


$git lo0g--pretty=raw-1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 

tree e33be9e8e7ca5f887c7d5601054f2f510e6744b8 

parent 81993234fc12a325d303eccea20f6fd629412712 

author Jiang Xin<jiangxin@ossxp.com>1291882031+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291882892+0800 
Add Images for git treeview. 

Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


参数 --pretty=fuller 会 同时 显示 作者 和 提交 者 ， 两 者 可 以 不 同 。 


$git lo0g--pretty=fuller-1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Thu Dec 9 16:07:11 2010+0800 
Commit:Jiang Xin<]jiangxin@ossxp.com> 
CommitDate:Thu Dec 9 16:21:32 2010+0800 

Add Images for git treeview. 
Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


参数 --pretty=oneline 显 然 会 提供 最 精简 的 日 志 输 出 。 也 可 以 使 用 -- 
oneline 参 数 ， 效 果 近 似 。 


$git lo0g--pretty=oneline-1 
6652a0dce6a5067732c0gef0a220810a7230655e Add Images for git 
treeview. 


如 有 果 只 想 查 看 和 分 析 某 一 个 提交 ， 也 可 以 使 用 git show 或 git cat- 
file 命 令 。 使 用 git show 显 示 里 程 碑 D 及 其 提交 : 


$git show D--stat 

tag D 

Tagger:Jiang Xin<jiangxin@ossxp.com> 
Date:Thu Dec 9 14:24:52 2010+0800 

create node D 

commit 212efce1548795aledb08e3708a50989fcd73cce 
Merge:e80aa74 2ab52ad 

Author:Jiang Xin<jiangxin@ossxp.com> 
Date:Thu Dec 9 14:06:34 2010+0800 

Commit D:merge G with H 

Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 
README | 2++ 

doc/D.txt |1+ 

doc/H.txt |1+ 

3 files changed,4 insertions(+),0 deletions(-) 


使 用 git cat-file 显 示 里 程 碑 D 及 其 提交 。 参 数 -p 的 含义 是 美观 的 输 
出 (pretty) 。 


$git cat-file-p DAO 

tree 1c22e90c6bf150ee1cde6cefb476abbb921f491 上 

parent e80aa7481beda65ae00e35afc4bc4b171f9boebf 

parent 2ab52ad2a30570109e71b56fa1780f0442059b3c 

author Jiang Xin<jiangxin@ossxp.com>1291874794+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291875877+0800 
Commit D:merge G with H 


Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


11.4.4 ”差异 比较 : git diff 


Git 差 异 比较 功能 在 前 面 的 实践 中 也 反复 地 接触 过 了 ， 尤 其 是 在 介 
绍 暂 存 区 的 相关 章节 重点 介绍 了 git diff 命 令 如 何 对 工作 区 、 和 暂 存 区 、 
版 本 库 进行 比较 : 


比较 里 程 碑 B 和 里 程 碑 A， 用 命令 : git diffB A 


比较 工作 区 和 里 程 碑 A， 用 命令 : git diff A 


比较 和 暂 存 区 和 里 程 碑 A， 用 命令 : git diff--cached A 


比较 工作 区 和 和 暂 存 区 ， 用 命令 : git diff 


比较 暂 存 区 和 HEAD， 用 命令 : git diff--cached 
比较 工作 区 和 HEAD， 用 命令 :git diff HEAD 
1. 文 件 不 同 版 本 的 差异 比较 


荆 异 比较 还 可 以 使 用 路 径 参 数 ， 只 显示 不 同 版 本 间 该 路 径 下 文件 
的 差异 。 语 法 格式 如 下 : 


$git diff<commit1> <commit2>--<paths> 


2. 非 Git 目录 /文件 的 差异 比较 


命令 git diff 还 可 以 在 Git 版 本 库 之 外 执行 ， 对 韭 Git 目 录 进 行 比较 ， 
谍 像 GNU 的 diff 命 令 一 样 。 之 所 以 提供 这 个 功能 古 因为 Git 产 异 比较 命 
令 更 为 强大 ， 提 供 了 对 二 进 制 文件 差异 等 的 扩展 支持 。 语 法 格式 如 
下 : 


$git diff<path1i> <path2> 


3. 扩 展 的 差异 语法 


Git 扩 展 了 GNU 的 差异 比较 语法 ， 提 供 了 对 重 命 名 、 二 进 制 文件 、 
文件 权限 变更 的 文 持 。 本 书 第 7 篇 第 38 章 将 专题 介绍 。 


4. 逐 词 比较 ， 而 非 默认 的 逐 行 比较 


Git 的 差异 比较 默认 是 逐 行 比较 ， 分 别 显示 改动 前 的 行 和 改动 后 的 
行 ， 到 展 改动 在 哪里 还 需要 仔细 辨别 。Git 不 提供 一 种 逐 词 比较 的 输 
出 ， 有 的 人 会 更 喜欢 。 使 用 --word-diff 参 数 可 以 显示 逐 词 比较 。 


$git diff--word-diff 

diff--git a/src/book/02-use-git/080-git-history-travel.rst 
b/src/book/02-use- 

git/080-git-history-travel.rst 

index f740203..2dd3e6f 100644 

---a/sSrc/book/02-use-git/080-git-history-travel.rst 

+++b/src/book/02-use-git/080-git-history-travel.rst 

@@ -681,7+681,7 @@6Git 的 大 部 分 命令 可 以 使 用 提交 版 本 作为 参数 (如 :git 
diff), 


[-18:23:48 jiangxin@hp:~/gitwork/gitbook/src/book$-]{+$+}git 
lo0g--stat 

--OoNeline 工 , ,C 

Ocd7f2e commit C. 

README | 1+ 

doc/C.txt|1+ 


上 面 的 逐 词 差异 显示 是 有 颜色 的 : 删除 内 容 [-.………-] 用 红色 表示 ， 
添加 的 内 容 {+.……+} 用 绿色 表示 。 


11.4.5 ”文件 退 洲 :git blame 


在 软件 开发 过 程 中 当 发 现 Bug 并 定位 到 具体 的 代码 时 ，Git 的 文件 
妃 测 命令 可 以 指出 是 谁 在 什么 时 候 ， 以 及 什么 版 本 引入 的 此 Bug。 


当 针 对 文件 执行 git blame 命 令 时 ， 束 会 逐 行 显示 文件 ， 在 每 一 行 
的 行 首 显示 此 行 最 早 是 在 什么 版 本 引入 的 ， 由 谁 引入 的 。 


$ cd/path/to/my/workspace/gitdemo-commit-tree 

$ git blame README 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 1) DEMO program for 
git-scm-book. 

^Ae80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 2) 

Ae80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 3) Changes 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 4) ======= 

^e80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 5) 

81993234 (Jiang Xin 2010-12-09 14:30:15+0800 6) 

gcd7f2ea (Jiang Xin 2010-12-09 14:29:09+0800 7) 

776c5c9d (Jiang Xin 2010-12-09 14:27:31+0800 8) create node 

beb30ca7 (Jiang Xin 2010-12-09 14:11:01+0800 9) create node 

^3252fcc (Jiang Xin 2010-12-09 14:00:33+0800 10) * create node 


create node 
create node 


A A 站 


TWHOP 


i ^A634836c (Jiang Xin 2010-12-09 14:00:33+0800 11) * create node 
i ^83be369 (Jiang Xin 2010-12-09 14:00:33+0800 12) * create node 
212efce1 (Jiang Xin 2010-12-09 14:06:34+0800 13) * create node 
i ^2ab52ad (Jiang Xin 2010-12-09 14:00:33+0800 14) * create node 
^Ae80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 15) * create node 
G. 


^e80aa74 (Jiang Xin 2010-12-09 14:00:33+0800 16) * initialized. 


只 想 查 看 某 几 行 ， 使 用 - L nm 参数 ， 命 Hp 令 如 下 : 


$git blame-L 6,+5 README 
81993234(Jiang Xin 2010-12-09 14:30:15+0800 6) * create node A， 


Qcd7f2ea(Jiang Xin 2010-12-09 14:29:09+0800 7) * create node C， 


p 9 (Jiang Xi L ] :27:31 *0B800 8}) * create node BB. 
beb30ca7 yiang Xi [ ) 和 | 3] * create node 下 ， 
fcc (Jiang Xir ] 134:0 33 #0B800 10}) * create node J 


11.4.6 ”二 分 查找 : git bisect 


前 面 的 文件 追 湖 是 建立 在 问题 (Bug) 已 经 定位 〈 到 代码 上 ) 的 基础 之 上 ， 然 后 才能 通 
过 错误 的 行 〈 代 码 ) 找到 人 【提交 者 )， 打 板子 〈 教 育 或 惩罚 )。 那 么 如 何 定位 问题 呢 ? Git 
的 二 分 查找 命令 可 以 提供 帮助 ， 

二 分 查找 并 不 神秘 ， 也 不 是 万 灵 药 ， 是 建立 在 测试 的 基础 之 上 的 。 实 际 上 很 多 做 过 软件 
调试 的 人 都 可 能 使 用 过 :“ 最 新 的 版 本 出 现 Bug 了 ,但 是 在 给 某 客户 的 版 本 却 没 有 这 个 问题 ， 
所 以 问题 肯定 出 在 两 者 之 间 的 某 次 代码 提交 上 ”。 


1. 使 用 二 分 查找 


Git 提供 的 git bisect 命令 是 基于 版 本 库 的 、 自 动 化 的 问题 查找 和 定位 工具 ， 取 代 传 
统 软 件 测试 中 针对 软件 发 布 版 本 的 、 无 法 定位 到 代码 的 、 粗 放 式 的 测试 方法 。 

执行 二 分 查找 ， 在 发 现 问 题 后 ， 首 先 要 找到 一 个 正确 的 版 本 ， 如 果 所 发 现 的 问题 从 软件 
最 星 的 版 本 就 是 错 的 ， 那 么 就 没有 必要 执行 二 分 查找 了 ， 还 是 老 老实 实 的 Debug 吧 。 但 是 
如 果 能 够 找到 一 个 正确 的 版 本 ， 即 在 这 个 正确 的 版 本 上 问题 设 有 发 后， 那么 就 可 以 开始 使 用 
git bisect 命令 在 版 本 库 中 进行 二 分 查找 了 : 

(1) 工作 区 切换 到 已 知 的 “好 版 本 ”和 “ 坏 版 本 ”的 中 间 的 一 个 版 本 。 

(2) 执行 测试 ， 如 果 问 题 重 现 ， 则 将 版 本 库 当 前 版 本 库 标记 为 “ 坏 版 本 ， 如 果 问 题 没 
有 重 现 ， 则 将 当前 版 本 标记 为 “好 版 本 ”。 

(3) 重复 1-2， 直 至 最 终 找 到 第 一 个 导致 问题 出 现 的 版 本 . 

11-22 是 示例 版 本 库 标记 了 提交 ID 后 的 示意 图 ， 在 这 个 示例 版 本 库 中 试验 二 分 查找 流程 : 
首先 标记 最 新 提交 (HEAD) 是 “ 坏 的 ”，G 提交 是 好 的 ， 然 后 通过 查找 最 终 定位 到 坏 提 区 (B)。 


665280d 
(A) 8190323 


0 Ocd7f2e 


212efce 他 beb38ca 


e806aa74 ”2ab52ad 6€634836c 3252fcc 


图 11-22 二 分 法 寻找 坏 提 交 


在 下 面 的 试验 中 定义 坏 提 交 的 依据 很 商 单 ， 如 有 宁 在 doc 目 永 中 包含 
文件 B.txt， 则 此 版 本 是 “ 坏 ” 的 。 (这 个 示例 太 简 陋 ， 不 要 见笑 ， 聪 明 
的 读者 可 以 直接 通过 docB.txt 文 件 就 可 追溯 到 B 提 交 。) 


下 面 开 始 通过 手动 测试 (查找 doc/B.txt 存 在 与 否 ) ， 借 助 Git 二 分 
查找 定位 “问题 ?版 本 ， 具 体操 作 步 骤 如 下 。 


(1) 首先 确认 工作 在 master 分 支 。 


$cd/path/to/my/workspace/gitdemo-commit-tree/ 
$git checkout master 
Already on 'master' 


$git bisect start 


(3) 当前 版 本 已 经 是 “ 坏 提 交 *， 因 为 存在 文件 doc/B.txt。 而 G 版 
本 是 “好 提交 ”， 因 为 不 存在 文件 doc/B.txt 。 


$git cat-file-t master:doc/B.txt 

blob 

$git cat-file-t G:doc/B.txt 

fatal:Not a valid object name G:doc/B.txt 


(4) 将 当前 版 本 (HEAD) 标记 为 “ 坏 提交 *， 将 G 版 本 标记 为 “好 


$git bisect bad 

$git bisect good G 

Bisecting:5 revisions left to test after this(roughly 2 steps) 
[ocd7f2ea245d90d414e502467ac749f36aa32cc4]commit C. 


(5) 自动 定位 到 C 提 交 。 没 有 文件 doc/B.txt， 也 是 一 个 好 提交 。 


$git describe 

C 

$1s doc/B.txt 

1s :无 法 访问 doc/B .txt :没有 那个 文件 或 目录 


(6) 标记 当前 版 本 (C 提 交 ) 为 “好 提交 ”。 


$git bisect good 
Bisecting:3 revisions left to test after this(roughly 2 steps) 
[212efce1548795aiedb08e3708a50989fcd73cce]Commit D:merge G with 


(7) 现在 定位 到 D 版 本 ， 这 也 是 一 个 “好 提交 ”。 


$git describe 

D 

$1ls doc/B.txt 

1s :无 法 访问 doc/B .txt :没有 那个 文件 或 目录 


(8) 标记 当前 版 本 (D 提 交 ) 为 “好 提交 ”。 


$git bisect good 

Bisecting:1 revision left to test after this(roughly 1 step) 

[776c5c9da9dcbb7e463c061d965ea47e73853b6e]Commit B:merge D with 
E and F 


(9) 现在 定位 到 B 版 本 ， 这 是 一 个 “ 坏 提交 ”。 


$git bisect bad 
Bisecting:© revisions left to test after this(roughly 0 steps) 
[83be36956c007d7bfffe13805dd2081839fd3603]commit E. 


(10) 现在 定位 到 E 版 本 ， 这 是 一 个 “好 提交 ”。 当 标记 FE 为 好 提交 
之 后 ， 输 出 显示 已 经 成 功 定位 到 引入 坏 提交 的 最 接近 的 版 本 。 


$git bisect good 
776c5c9da9dcbb7e463c061d965ea47e73853b6e is the first bad commit 


(11) 最 终 定位 的 坏 提 交 用 引用 refs/bisect/bad 标 识 。 可 以 用 如 下 
方法 切换 到 该 版 本 。 
$git checkout bisect/bad 


Previous HEAD position was 83be369.,..commit E. 
HEAD is now at 776c5c9,. ,Commit B:merge D with E and F 


(12) 当 对 "Bug" 定 位 和 修复 后 ， 撤 销 二 分 查找 在 版 本 库 中 遗留 的 
临时 文件 和 3 引用。 撤销 二 分 查找 后 ， 版 本 库 切 换 回执 行 二 分 查找 之 前 
所 在 的 分 文 。 


$git bisect reset 
Previous HEAD position was 776cC5c9.,..Commit B:merge D with E and 


Switched to branch 'master' 


2. 把 “好 提交 ”标记 成 了 “ 坏 提交 ”该 怎么 办 ? 


在 执行 二 分 查找 的 过 程 中 ， 一 不 小 心 歼 有 可 能 犯错 ， 将 “好 提 
区 ”标记 为 “ 坏 提 交 ”*”， 或 者 相反 。 这 将 导致 前 面 的 查找 过 程 也 前 功 尽 
弃 。 为 此 ，Git 的 二 分 查找 提供 了 一 个 恢复 查找 进度 的 办 法 ， 具 体操 作 
过 程 如 下 。 


J 


(1) 例如 对 提交 E， 本 来 是 一 个 “好 版 本 ” 却 被 错误 的 标记 为 “ 坏 版 


$git bisect bad 
83be36956c007d7bfffe13805dd2081839fd3603 is the first bad commit 


(2) 用 git bisect log 命 令 查 看 二 分 查找 的 日 志 记 录 。 
把 二 分 查找 的 日 志保 存在 一 个 文件 中 。 


$git bisect 1og>1ogfile 


(3) 编辑 这 个 文件 ， 删 除 记录 了 错误 动作 的 行 。 
以 井 号 (#) 开始 的 行 是 注释 。 


$cat logfile 

#bad: [6652aQdce6a5067732c00ef0a220810a7230655e]Add Images for 
git treeview. 

#go0d: [e80aa7481ibeda65ae00e35afc4bc4b171f9bOebf ]commit 6G. 

git bisect start 'master' 'G' 

#goo0d: [Ocd7f2ea245d90d414e502467ac749f36aa32cc4]commit C. 

git bisect good Qcd7f2ea245d90d414e502467ac749f36aa32cc4 

#go0d: [212efce1548795aledb08e3708a50989fcd73cce]Commit D:merge G 
with H 

git bisect good 212efce1548795a1ledb08e3708a50989fcd73cce 


#bad:[776c5c9da9dcbb7e463c061d965ea47e73853b6e]Commit B:merge D 
with E and F 
git bisect bad 776c5c9da9dcbb7e463c061d965ea47e73853b6e 


(4) 结束 正在 进行 的 出 错 的 二 分 查找 。 


$git bisect reset 
Previous HEAD position was 83be369.,..commit E. 
Switched to branch 'master' 


(5) 通过 日 志文 件 恢复 进度 ， 重 启 二 分 查找 。 


$git bisect replay logfile 

We are not bisecting. 

Bisecting:5 revisions left to test after this(roughly 2 steps) 
[ocd7f2ea245d90d414e502467ac749f36aa32cc4]commit C. 
Bisecting:© revisions left to test after this(roughly © steps) 
[83be36956c007d7bfffe13805dd2081839fd3603]commit E. 


(6) 再 一 次 回 到 了 提交 E， 这 一 次 不 要 标记 错 了 哦 。 


$git describe 

E 

$git bisect good 

776c5c9da9dcbb7e463c061d965ea47e73853b6e is the first bad commit 


二 分 碍 找 使 用 目 动 化 测试 


Git 的 二 分 查找 命令 文 持 run 子 命令 ， 可 以 运行 一 个 目 动 化 测试 脚 
本 ， 实 现 目 动 的 二 分 查找 。 


如 果 脚 本 的 退出 码 是 90， 正在 测试 的 版 本 是 一 个 “好 版 本 ”。 


如 果 脚 本 的 退出 码 是 125， 正 在 测试 的 版 本 被 跳 过 。 


如 果 脚本 的 退出 码 是 1 到 127 (125 除 外 ) ， 正 在 测试 的 版 本 是 一 
个 “ 坏 版 本 ”。 


为 本 例 写 一 个 自动 化 测试 太 简 音 了， 无非 束 是 判断 文件 是 否 存 
在 ， 存 在 则 返回 错误 码 1， 不 存在 则 返回 错误 码 0。 测 试 脚本 good-or- 
bad.sh 如 下 : 
#! /bin/sh 


[-f doc/B.txt]&&exit 1 
exit 0 


用 此 脚本 实现 目 动 化 二 分 查找 的 过 程 非常 简单 ， 具 体操 作 步 又 如 
六 


(1) 从 已 知 的 坏 版 本 master 和 好 版 本 G 开 始 新 一 轮 的 二 分 查找 。 


$git bisect start master 6 
Bisecting:5 revisions left to test after this(roughly 2 steps) 
[ocd7f2ea245d90d414e502467ac749f36aa32cc4]commit C. 


(2) 自动 化 测试 ， 使 用 脚本 good-or-bad.sh 。 


$git bisect run sh good-or-bad.sh 

running sh good-or-bad.sh 

Bisecting:3 revisions left to test after this(roughly 2 steps) 
[212efce1548795aiedb08e3708a50989fcd73cce]Commit D:merge G with 


running sh good-or-bad.sh 
Bisecting:1 revision left to test after this(roughly 1 step) 


[776c5c9da9dcbb7e463c061d965ea47e73853b6e]Commit B:merge D with 
E and F 

running sh good-or-bad.sh 

Bisecting:© revisions left to test after this(roughly 0 steps) 

[83be36956c007d7bfffe13805dd2081839fd3603]commit E. 

running sh good-or-bad.sh 

776c5c9da9dcbb7e463c061d965ea47e73853b6e is the first bad commit 

bisect run success 


(3) 定位 到 的 “ 坏 版 本 ”是 B。 


$git describe refs/bisect/bad 
B 


11.4.7 ”获取 历史 版 本 


提取 历史 提交 中 的 文件 无 非 束 是 表 11-1 中 的 操作 ， 在 之 前 的 实践 
中 已 多 次 用 到 ， 这 里 不 再 痪 述 。 


表 11-1 获取 文件 历史 版 本 命令 一 览 表 
动作 命令 格式 示例 


D git js-trec 776csec9 README 
© git ls-tree -r refs/tags/D doc 


O git checkout rcfs/tags/D — README 
© git chcckout 776c5c9 一 doc 


查看 历史 提交 的 目录 树 git ls-tfee <tree-ish> <paths> 


检 出 某 文 件 的 历史 版 本 sit checkout <commit> -- <paths> 


Ogit show 887113d:README > 


检 出 某 文件 的 历 虫 版 本 到 其 化 文件 名 | git show <commit>:<file> > new_name README OLD 


第 12 章 ”改变 历史 


我 是 电影 《 回 到 未 来 》 的 粉丝 ， 偶 尔 会 做 梦 ， 梦 见 穿梭 到 未 来 拿 
回 一 本 2000-2050 体 育 年 鉴 。 操 作 Git 也 可 以 体验 到 穿梭 时 空 的 感觉 ， 
因为 Git 像 极 了 一 个 时 光 机 器 ， 不 但 允许 你 在 历史 中 穿梭 ， 而 且 还 能 够 
改变 历史 3 


本 章 的 最 开始 将 介绍 两 种 最 镜 单 和 最 第 用 的 历史 变更 操作 一 一 “ 悔 
棋 ” 操 作 ， 就 是 对 刚刚 进行 的 一 次 或 几 次 提交 进行 修补 或 撤销 。 对 于 跳 
跃 式 的 历史 记录 的 变更 ， 即 仅 对 过 去 某 一 个 或 蘑 几 个 提交 做 出 改变 ， 
会 在 “ 回 到 未 来 ”小 节 详 细 介 绍 。 在 “丢弃 历史 ”小 市 会 介绍 一 种 版 本 库 
瘦 喘 的 方法 ， 这 可 能 会 在 某 些 特定 的 场合 用 到 。 


作为 分 布 式 版 本 控制 系统 ， 一 旦 版 本 库 被 多 人 共 诗 ， 改 变 历 史 束 
可 能 是 无 法 完成 的 任务 。 在 本 章 的 最 后 ， 介 绍 还 原 操 作 以 实现 在 不 改 
变 历史 提交 的 情况 下 还 原 错 误 的 改动 。 


12.1 悔 棋 


在 日 单 的 Git 操 作 中 ， 会 经 党 出 现 这 样 的 状况 ， 输 入 git commit 命 
令 刚刚 融 下 回 车 键 束 后 悔 了 : 可 能 是 提交 说 明 中 出 现 了 错别字 ， 或 者 
有 文件 起 记 提交 ， 或 者 有 的 修改 不 应 该 提交 ， 诸 如 此 类 。 


像 Subversion 那 样 的 集中 式 版 本 控制 系统 是 “ 落 子 无 悔 " 的 系统 ， 只 
能 叹 一 口气 责怪 目 己 太 不 小 心 了 。 然 后 根据 实际 情况 弥补 : 马上 做 一 
次 新 提交 改正 前 面 的 错误 ;或 者 只 能 将 错 驶 钳 ， 错 误 的 提交 说 明 殉 让 
它 一 直 错 下 去 吧 。 因 为 大 部 分 Subversion 管 理 员 不 敢 或 不 会 放 开 修 改 提 
交 说 明 的 功能 ， 从 而 导致 无 法 对 提交 说 明 进 行 修改 。 


Git 提 供 了 “ 悔 棋 ”的 操作 ， 甚 至 因为 “ 单 步 悔 棋 ” 古 如 此 经 常 的 发 
生 ， 力 至 于 Git 提 供 了 一 个 简洁 的 操作 一 一 修补 式 提交 ， 命 仿古 :git 


commit--amend ° 


看 看 当前 版 本 库 最 新 的 两 次 提交 : 


$cd/path/to/my/workspace/demo 

$git 1og--Stat-2 

commit 822b4aeed5de74f949c9faa5b281001eb5439444 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:wed Dec 8 16:27:41 2010+0800 

测试 使 用 qgit 提 交 。 

README | 1+ 

src/hello.h|2-- 

2 files changed,1 insertions(+),2 deletions(-) 
commit 613486c17842d139871e0f1ib0e9191d2b6177c9f 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Dec 7 19:43:39 2010+0800 

偷懒 了 , 直接 用 -a 参数 直接 提交 。 

src/hello.h|i1+ 

1 files changed,1 insertions(+),0 deletions(-) 


最 靳 一次 的 提交 的 确 古 在 上 一 章 使 用 ggit 进 行 的 提交 ， 但 这 和 所 
区 内 容 无 天 ， 因 此 需要 改 掉 这 个 提交 的 提交 说 明 。 使 用 下 面 的 命令 即 
可 做 到 。 


$git commit--amend-m "Remove hello.h,which is useless." 
[master 7857772]Remove hello.h,which is useless. 

2 files changed,1 insertions(+),2 deletions(-) 

delete mode 100644 src/hello.h 


上 面 的 命令 使 用 了 -m 参 数 是 为 了 演示 的 方便 ， 实 际 上 完全 可 以 直 
接 输 入 git commit--amend， 在 弹出 的 提交 说 明 编 辑 界面 修改 提交 说 
明 ， 然 后 保存 退出 完成 修补 提交 


下 面 再 看 看 最 近 两 次 的 提交 说 明 ， 可 以 看 到 最 新 的 提交 说 明 更 改 
了 (包括 提交 的 SHA1 哈 希 值 ， 而 它 的 父 提交 ( 即 前 一 次 提交 ) 没有 


$git 1og--Stat-2 

commit 78577724305e3e20aa9f2757ac5531d037d612a6 
Author:Jiang Xin<]jiangxin@ossxp.com> 

Date:wed Dec 8 16:27:41 2010+0800 

Remove hello.h,which is useless. 

README | 1+ 

src/hello.h|2-- 

2 files changed,1 insertions(+),2 deletions(-) 
commit 613486c17842d139871egf1boe9191d2b6177c9f 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Dec 7 19:43:39 2010+0800 

偷懒 了 , 直接 用 -a 参数 直接 提交 。 

src/hello.h|1+ 

1 files changed,1 insertions(+),0 deletions(-) 


如 果 最 后 一 步 操 作 不 想 删 除 文 件 src/hello.h， 而 只 是 想 修改 
README， 则 可 以 按照 下 面 的 方法 进行 修补 操作 ， 具 体 控 作 过 程 如 
下 。 


(1) 还 原 删 除 的 src/hello.h 文 件 。 


$git checkout HEAD^--src/hello.h 


(2) 此 时 查看 状态 .会 看 到 src/hello.h 被 重新 添加 回 暂 存 区 。 


$git status 
#0n branch master 
#Changes to be committed: 


#(UusSe "git reset HEAD<file>..."to unstage) 
# 

#new file:src/hello.h 

# 


(3) 执行 修补 提交 ， 不 过 提交 说 明 是 不 是 也 要 更 改 呢 ， 因 为 毕竟 
这 次 提交 不 会 删除 文件 了 。 


$git commit--amend-m "commit with--amend test." 
[master 2b45206]commit with--amend test. 
1 files changed,1 insertions(+),0 deletions(-) 


(4) 再 次 查看 最 近 的 两 次 提交 ， 会 发 现 最 新 的 提交 不 再 删除 文件 
src/hello.h 了 。 


$git 1og--Stat-2 

commit 2b452066ef6e92bceb999cf94fcce24afb652259 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:wed Dec 8 16:27:41 2010+0800 

commit with--amend test ， 

README | 1+ 

1 files changed,1 insertions(+),0 deletions(-) 
commit 613486c17842d139871e0f1ib0e9191d2b6177c9f 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Dec 7 19:43:39 2010+0800 


偷懒 了 , 直接 用 - a 参 数 直 接 提 区。 
src/hello.h|1+ 
1 files changed,1 insertions(+),0 deletions(-) 


12.2 多 步 悔 棋 


Git 能 够 提供 悔 棋 的 奥秘 在 于 Git 的 重 置 命令 。 实 际 上 上 面 介 绍 的 
单 步 悔 棋 也 可 以 用 重 置 命令 来 实现 ， 只 不 过 Git 提 供 了 一 个 更 好 用 更 简 
洁 的 修补 提交 命令 而 已 。 多 步 悔 棋 顾 名 思 义 就 是 可 以 取消 最 新 连续 的 
多 次 提交 。 多 次 悔 棋 并 非 是 所 有 分 布 式 版 本 控制 系统 都 具有 的 功能 ， 
像 Mercurial/Hg 只 能 对 最 新 提交 悔 棋 一 次 (除非 使 用 MQ 插件 ) 。Git 因 
为 有 了 强大 的 重 置 命令 ， 可 以 任意 悔 棋 多 次 。 


多 步 悔 棋 会 在 什么 场合 用 到 呢 ? 软件 开发 中 针对 某 个 特性 功能 的 
开发 束 是 一 例 。 某 个 开发 工程 师 领 受 某 个 特性 开发 的 任务 ， 于 是 在 本 
地 版 本 库 进 行 了 一 系列 开发 、 测 试 、 修 补 、 再 测试 的 流程 ， 最 终 特 性 
功能 开发 完毕 后 可 能 在 版 本 库 中 留 下 了 多 次 提交 。 在 将 本 地 版 本 库 改 
动 推送 (PUSH) 到 团队 协同 工作 的 核心 版 本 库 时 ， 这 个 开发 人 员 束 
想 用 多 步 悔 棋 的 操作 ， 将 多 个 试验 性 的 提交 合并 为 一 个 完整 的 提交 。 


以 DEMO 版 本 库 为 例 ， 看 看 版 本 库 最 近 的 三 次 提交 。 


$git lo0g--stat--pretty=oneline-3 

2b452066ef6e92bceb999cf94fcce24afb652259 commit with--amend 
test. 

README | 1+ 

1 files changed,1 insertions(+),0 deletions(-) 

613486c17842d139871egf1boe9191d2b6177c9f 偷 懒 了 , 直接 用 -a 参数 直接 提 
交 。 

src/hello.h|1+ 


1 files changed,1 insertions(+),0 deletions(-) 
48456abfaeab706a44880eabcd63ea14317c0be9 add hello.h 
src/hello.h|i1+ 

1 files changed,1 insertions(+),0 deletions(-) 


想 要 将 最 近 的 两 个 提交 压缩 为 一 个 ， 并 把 提交 说 明 改 为 "modify 
hello.h"， 可 以 使 用 如 下 方法 进行 操作 。 


(1) 使 用 --soft 参 数 调用 重 置 命令 ， 回 到 最 近 两 次 提交 之 前 。 


$git reset--soft HEADAA 


(2) 查看 版 本 状态 和 最 新 日 志 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USse "git reset HEAD<file>..."to unstage) 
# 

#modified :README 

#modified:src/hello.h 

江 

$git lo0g-1 

commit 48456abfaeab706a44880eabcd63ea14317c0be9 
Author:Jiang Xin<jiangxin@ossxp.com> 
Date:Tue Dec 7 19:39:10 2010+0800 

add hello.h 


(3) 执行 提交 操作 ， 即 完成 最 新 两 个 提交 压缩 为 一 个 提交 的 操 
作 。 
$git commit-m "modify hello.h" 


[master b6foboa]jmodify hello.h 
2 files changed,2 insertions(+),0 deletions(-) 


(4) 看 看 提交 日 志 ,“ 多 步 悔 棋 ” 操 作成 功 。 


$git log--stat--pretty=oneline-2 
b6fobo0a5237bc85de1863dbd1c05820f8736c76f modify hello.h 
README | 1+ 

src/hello.h|1+ 

2 files changed,2 insertions(+),0 deletions(-) 
48456abfaeab706a44880eabcd63ea14317c0be9 add hello.h 
src/hello.h|1+ 

1 files changed,1 insertions(+),0 deletions(-) 


12.3 ”同色 未 来 


影 《 回 到 未 来 》 (Back to Future) 第 二 集 ， 老 毕 福 偷 走时 光 
车 ， 到 过 去 (1955 年 ) 给 了 小 毕 福 一 本 书 ， 导 致 未 来 大 变 。 


也 就 是 过 去 的 菜 个 时间 
时 间 线 被 扭曲 


图 12-1 布衣 博士 正在 解释 为 何 产 生 两 个 平行 的 未 来 


Git 这 一 台 “ 时 光 机 ”也 有 这 样 的 能 力 ， 或 者 说 也 具有 这 样 的 行为 。 
更 改 历史 提交 (SHA1 哈 希 值 变更 ) 后 ， 即 使 后 续 提交 的 内 容 和 属性 都 
一 致 ， 但 是 因为 后 续 提 区 中 有 一 个 属性 是 父 提 交 的 SHAI1 哈 币值 ， 所 以 
一 个 历史 提交 的 改变 会 引起 连锁 变化 ， 导 致 所 有 的 后 续 提交 都 发 生变 
化 ， 形 成 两 条 平行 的 时 间 线 : 一 个 是 变更 前 的 提交 时 间 线 ， 男 外 一 条 
古 更 改 历史 后 新 的 提交 时 间 线 。 


把 此 次 实践 比喻 成 一 次 电影 (《 回 到 未 来 》) 拍摄 的 话 ， 舞 台 依 
然 是 之 前 的 DEMO 版 本 库 ， 而 剧本 是 这 样 的。 


角色 : 最 近 的 六 次 提交 。 分 别 依 据 提交 顺序 ， 编 号 为 A、B、C、 
D、E、F。 


$git 1og--oneline-6 

b6fo9boa modify hello.h#F 

48456ab add hello.h#E 

3488f2c move.gitignore outside also works .#D 
b3af728 ignore object files.#C 

d71ce92 Hello world initialized.#B 

cO24f34 README is from welcome.txt.#A 


坏蛋 : 提交 D 。 


印 不 再 需要 对 .gitignore 文 件 进行 移动 的 提交 ， 或 者 这 个 提交 将 和 


前 一 次 提交 


(CC ) 压缩 为 一 个 。 
口 前 内 : 故事 人 物 依次 出 场 ， 坏 蛋 D 在 图 中 被 特殊 标记 ， 如 图 12-2 所 示 。 


BO— © — © D BD—€ 


图 12-2 提交 示意 区 


口 第 一 幕 : 抛弃 提交 D， 将 正确 的 提交 E 和 下 重新 “嫁接 ”到 提交 C 上 ， 最 终 坏蛋 被 
消灭 ， 如 图 12-3 所 示 。 


图 12-3 ”抛弃 DD 提交 示意 图 


口 第 二 幕 : 坏蛋 D 被 C 感化 ， 融合 为 “CD” 复 合体 ，E 和 下 重新 “嫁接 ”到 “CD” 复 
合体 上 ， 最 终 大 团 回 结 局 ， 如 图 12-4 所 示 。 


图 12-4 C、D 提交 合并 示意 图 


口 道具 : 分 别 使 用 三 辆 不 同 的 时 光 车 来 完成 “ 回 到 未 来 ” 
它们 分 别 是 : “核能 跑车 ”一 一 拣选 操作 .“ 请 洁 能 源 飞 车 ”一 一 变 基 操 作 .“ 蒸 汽 为 
动力 的 飞行 火车 ” 交互 式 变 基 操 作 ， 


12.3.1 时间 旅 行 一 


“ 回 到 未 来 》 第 一 集 ， 布 朗 博 士 设 计 的 第 一 款 时 间 旅 行车 是 一 辆 跑车 ， 使 用 核燃料 : 
钙 。 与 之 对 应 ， 此 次 实践 使 用 的 工具 也 役 有 太 出 平 想象 之 外 ， 用 一 条 新 的 指令 一 拣选 指令 
(git cherry-pick) 实现 提交 在 新 的 分 支 上 “ 重 放 ”。 

拣选 指令 一 一 git cherry-pick， 其 含义 是 从 众多 的 提交 中 挑选 出 一 个 提交 应 用 在 当 
前 的 工作 分 支 中 。 该 命令 需要 提供 一 个 提交 ID 作为 参数 ， 操 作 过 程 相当 于 将 该 提交 导出 为 
补 于 文件 ， 然 后 在 当前 HEAD 上 重 放 ， 形 成 无 论 内 容 还 是 提交 说 明 都 一 致 的 提交 ， 

首先 对 版 本 库 要 “ 参 演 ”的 和 角色 进行 标记 ， 使 用 尚未 正式 介绍 的 命令 git tag《【 无 非 


束 是 在 特定 命名 空间 建立 “固定 ”的 引用 ， 用 于 对 提交 进行 标 


识 ) 。 
$git tag F 
$git tag E HEADA^ 
$git tag D HEADAA 
$git tag C HEADAAA 
$git tag B HEAD~4 
$git tag A HEAD~5 


通过 日 志 ， 可 以 看 到 被 标记 的 6 个 提交 


$git lo0g--oneline--decorate-6 
b6f0boa(HEAD,tag:F,master)modify hello.h 
48456ab(tag:E)add hello.h 
3488f2c(tag:D)move.gitignore outside also works. 
b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world in itialized. 
cO24f34(tag:A)README is from welcome.txt. 


1. 现 在 演出 第 一 人 幕 : 干掉 坏蛋 D 
(1) 执行 git checkout 命 令 ， 暂 时 将 HEAD 头 指针 切换 到 C。 


切换 过 程 显示 处 于 非 跟踪 状态 的 警告 ， 没 有 关系 ， 因 为 剧情 需 
要 o 


$git checkout C 

Note:checking out 'C'. 

You are in 'detached HEAD' state.You can look around,make 
experimental 

changes and commit them,and you can discard any commits you make 
in this 


state without impacting any branches by performing another 
checkout. 

If you want to create a new branch to retain commits you 
create,you may 

do so(now or later)by using-b with the checkout command 
again.Example: 

git checkout-b new_branch_name 

HEAD is now at b3af728...ignore object files. 


(2) 执行 拣选 操作 将 E 提 交 在 当前 HEAD 上 重 放 。 


因为 E 和 master^ 显 然 指 回 同一 角色 ， 因 此 可 以 用 下 面 的 语法 。 


$git cherry-pick master 人 ^ 

[detached HEAD fa0b076]add hello.h 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 src/hello.h 


(3) 执行 拣选 操作 将 F 提 交 在 当前 HEAD 上 重 放 。 
FE 和 master 也 具有 相同 指向 。 


$git cherry-pick master 
[detached HEAD f677821]modify hello.h 
2 files changed,2 insertions(+),0 deletions(-) 


(4) 通过 日 志 可 以 看 到 坏蛋 D 已 经 不 在 了 。 


$s git log -~oneline ~-decorate -6 

f677821 (HEAD)} modify hello,h 

fa0b0376 add hello.h 

b3af728 itag: C) ignore object files, 

qd71ce92 [tag: hello 1.0, tag: B) Hello world initialized, 
CO24f34 {tag: A) README is from welcome,txt, 

63992f0 restore file: welcome .txt 


(5) 通过 日 志 还 可 以 看 出 来 ， 最 新 两 次 提交 的 原始 创作 日 期 (AuthorDate) 和 提交 日 期 
CCommitDate) 不 同 。AuthorDate 是 拣选 提交 的 原始 更 改 时 间 ， 而 CommitDate 是 拣选 操作 
时 的 时 间 ， 因 此 拣选 后 的 新 提交 的 SHA1 险 希 值 也 不 同 于 所 拣选 的 原 提 交 的 SHA1 哈 希 值 。 


§ git log -~-pretty=fuller ~-decorate -2 
commit f677821dfciSacc22ca4lb48bgebaabsac2d2fea (HEAD) 


Author: Jiang Xin <ijiangxingossxp.com> 
AuthorDate: Sun Dec 12 12:11:00 2010 +080¢ 
Commit : Jiang Xin <iiangxinBossxp,com> 


CommitDate: Sun Dec 12 16:20:14 2010 +0800 
modify hello.h 


commit faQbhn7éde6n0asaeadT0Sac299090153c6328ag 


Author: Jiang Xin <ijiangxin@ossxp.com> 
AuthorDate: Tue Dec 7 19:39:10 2010 +0800 
Commit: Jiang Xin <iiangxinseossxp.com> 


CommitDate: Sun Dec 12 16:18:34 2010 +0800 


add hello.h 


(6) 最 重要 的 一 步 操作 ， 就 是 要 将 master 分 支 重 置 到 新 的 提交 ID (f677821) 上 。 
下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEAD@{1} 相当 于 切换 回 master 分 支 前 的 
HEAD 指向 ， 即 f677821. 


$ git checkout master 

Previous HEAD position was f£f677821... modify hello.h 
Switched to branch ‘master! 

$ git reset -~hard HEAD@{1} 

HEAD is now at f677821 modify hellc.h 


(7) 使 用 qgit 查看 版 本 库 提交 历史 ， 如 图 12-5 所 示 。 


author Date 


10-12-7 PM7:39 


10-12:12 PM12-11 | 
10-12-7 PM7:39 | 
0 12 7 PM7;34 | 
10.12.7 PM7;21 
10.12.7 PM6:33 
. 10-12-7 PM2:50 
restore file: welcome txt 3 X 9xin 10-12-7 PM2:32 


12-5 qgit 吕 示 的 提交 分 支 图 


2. 幕 布 拉 上 ， 后 台 重 新 布景 


为 了 第 二 幕 能 够 顺利 演出 ， 需 要 将 master 分 支 重新 置 回 到 提交 F 
上 。 执 行 下面 的 操作 完成 < 重新 布景 ”。 


$git checkout master 

Already on 'master' 

$git reset--hard F 

HEAD is now at b6foboa modify hello.h 

$git log--oneline--decorate-6 
b6f0boa(HEAD,tag:F,master)modify hello.h 
48456ab(tag:E)add hello.h 
3488f2c(tag:D)move.gitignore outside also works. 
b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 


景 完毕 ， 大 幕 即将 再 次 拉 开 。 
3. 现 在 演出 第 二 幕 : 坏蛋 D 被 感化 ， 融 入 社会 
(1) 执行 git checkout 命 令 ， 暂 时 将 HEAD 头 指针 切换 到 坏蛋 D 


切换 过 程 显示 处 于 非 跟踪 状态 的 警告 ， 没 有 关系 ， 因 为 剧情 需 
要 o 


$git checkout D 

Note:checking out 'D'. 

You are in 'detached HEAD' state.You can look around,make 
experimental 

changes and commit them,and you can discard any commits you make 
in this 

state without impacting any branches by performing another 
checkout. 

If you want to create a new branch to retain commits you 
create,you may 

do so(now or later)by using-b with the checkout command 
again.Example: 


git checkout-b new_branch_name 
HEAD is now at 3488f2c...move.gitignore outside also works. 


(2) 悔 棋 两 次 ， 以 便 将 C 和 DD 融合 。 


$git reset--soft HEADAA 


(3) 执行 提交 ， 提 交 说 明 重 用 C 提 交 的 提交 说 明 。 


$git commit-C C 

[detached HEAD 53e621c]ignore object files. 

1 files changed,3 insertions(+),0 deletions(-) 
create mode 100644.gitignore 


(4) 执行 拒 选 操作 将 FE 提交 在 当前 HEAD 上 重 放 。 


$git cherry-pick E 


[detachead HEAD if99f82] ada hello.h 
1 files changed, 1 insertions{+}, 0 deletions!-) 
create mode 100644 src/hello.h 


(5) 执行 拣选 操作 将 下 提交 在 当前 HEAD 上 重 放 . 


S git cherry-pick F 
[detached HEAD 2f13d3a] modify hello.h 


2 files changed, 2 insertions (+)，0 deletions{- 
(6) 通过 日 志 可 以 看 到 提交 C 和 DD 被 融合 ， 所 以 在 日 志 中 看 不 到 C 的 标签 


§ git log -~-oneline -~-decorate -6 

2f13G3a {HEAD} modify helilo.h 

1f99f£82 add hello.h 

S3e621c ignore obiject files, 

d71ce92 [tag: hello 1.0, tag; B) Hello world initialized 
c024f34 {tag: A) README is from welcome .txt 

E3992f0 reastore file: welcome.txt 


(7) 最 重要 的 一 步 操 作 ， 就 是 要 将 master 分 支 指向 新 的 提交 ID (2f13d3a) 上 . 
下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEAD@11} 相当 于 切换 回 master 分 支 前 的 
HEAD 指向 ， 即 2f13d3a， 


$ git checkout master 

Previcus HEAD position was 2f1l3d3a... modify hello.h 
Switched tao branch ‘master' 

$ git reset -~--hard HEAD@{1} 

HERAD is now at 2f13d3a modify helio,h 


(8) 使 用 gitk 查看 版 本 库 的 提交 历史 ， 如 图 12-6 所 示 。 


Omaster] mooiy hooh | Jiang Xin cfangxin@ opeom> | 201042421 人 e1100 
多 acd helloh Jiang Xin <fangxin@ossxp com> 2010-12-07 1 全 39.10 
nore oblect files Jiang Xin <jarngxin@ossxpcom> | 2010.42.07 19.21.99 
性 modity hallo h Jiang Xin < 了 rngxinG@ossxpPcom> |2010-12-12 1 人 1100 
一 Sid hello h Jiang Xin <jangxin@ossxp.com» 2010-142.07 19.39:10 
-<D| move gitignore outside also works Jiang Xin <jangxin@ossxp.com> 2010-12.07 1934:37 

<C| jgnore object fies. Jiang Xin <Fangxin@ossxpcom» |2010-12.07 1&21:39 


一 一 sio_ 19 Hello werid initialized Jiang Xin <jiangxinG@ossxpPcom> |2010-12-07 19:33:45 
A README is from welccme txt. Jiang Xin <jangxin@ossxp.com>» 2010-12.07 14;5002 
restore fle welcome tx Jiang Xin <jiangxin@® ossxp com> 2010-42.07 14.3257 


图 12-6 ”gitk 显示 的 提交 分 支 图 


4. 别 忘 了 后 台 的 重新 布景 
为 了 接 下 来 的 时 间 旅 行 二 能 够 顺利 开始 ， 需 要 重新 布景 ， 将 master 分 支 重 新 置 回 到 提交 下 上 ， 


$ git checkout master 

Aliready on 'master 

$§ git reset --hard F 

HERAD is now at b6f0boa modify helio.h 


用 法 1:git rebase--onto<newbase><since><till> 
用 法 2:git rebase--onto<newbase><since> [HEAD] 
用 法 3:git rebase[--onto<since>]<since><till> 
用 法 4:git rebase[--onto<since>]<since> [HEAD] 


12.3.2 时间 旅行 二 


《 回 到 未 来 》 第 二 集 ， 布 朗 博 十 改进 的 时 间 旅 行车 使 用 了 未 来 科 
技 ， 是 陆 天 两 用 的 飞车 ， 而 且 燃 料 不 再 依赖 核 物质 ， 而 是 使 用 无 处 不 
在 的 生活 垃圾 。 而 此 次 实践 使 用 的 工具 也 进行 了 升级 ， 采 用 强大 的 git 


rebase 命 令 。 


命令 git rebase 征 对 提交 执行 变 基 操作 ， 即 可 以 实现 将 指定 范围 的 
是 交 “ 嫁 接 ? 到 另外 一 个 提交 之 上 。 其 常用 的 命令 行 格 式 有 : 


法 1:git rebase--onto<newbase><since><till> 
法 2:git rebase--onto<newbase><since> 

法 3:git rebase<since><till> 

法 4:git rebase<since> 

法 5:git rebase-i... 
法 6:git rebase--continue 
法 7:git rebase--skip 

法 8:git rebase--abort 


卢 


不 要 被 上 面 的 语法 吓 到 ， 用 法 5 会 在 下 节 (时 间 旅行 三 ) 中 予以 介 
绍 ， 后 三 种 用 法 则 是 变 基 运 行 过 程 被 中 断 时 可 采用 的 命令 一 继续 变 
基 或 终止 等 。 


用 法 6 是 在 变 基 如 到 冲突 而 暂停 的 情况 下 ， 先 完成 冲突 解决 (添加 
到 暂 存 区 ， 不 提交 ) ， 然 后 在 恢复 变 基 操作 的 时 候 使 用 该 命令 。 


用 法 7 是 在 变 基 过 到 冲突 而 暂停 的 情况 下 ， 跳 过 当前 提交 的 时 候 使 


用 法 8 是 在 变 基 过 到 冲突 而 暂停 的 情况 下 ， 终 止 变 基 操作 ， 回 到 之 
前 的 分 文 时 候 使 用 。 


而 前 四 个 用 法 如 果 把 省 略 的 参数 补 上 ( 方 插 号 内 是 省 上 略 掉 的 参 
数 ) ， 看 起 来 和 用 法 1 就 都 一 致 了 。 


下 面 就 以 归 一 化 的 git rebase 命 令 格式 来 介绍 其 用 法 。 
命令 格式 :git rebase--onto<newbase><since> <till> 
变 基 操作 的 过 程 : 

(1) 首先 会 执行 git checkout 切 换 到 <til>。 


因为 会 切换 到 <til> ， 因 此 如 果 <t 记 > 指向 的 不 是 一 个 分 支 (如 
master) ， 则 变 基 操作 是 在 detached HEAD (分 离 头 指针 ) 状态 进行 
的 ， 当 变 基 结 束 后 ， 还 要 像 在 “时 间 旅 行 一 ”中 那样 ， 对 master 分 支 执 
行 重 置 以 实现 变 基 结果 在 分 文中 生效 。 


(2) 将 <since>..<ti> 所 标识 的 提交 范围 写 到 一 个 临时 文件 


还 记得 前 面 介 绍 的 版 本 范围 语法 吗 ，<since>..<til> 是 指 包 括 
<til> 的 所 有 历史 提交 排除 < since> 及 <since> 的 历史 提交 后 形成 的 


CD 


(3) 将 当前 分 文 强制 重 置 (git reset--hard) 到 <newbase>。 相 


当 于 执行 : git reset--hard< newbase> 之 。 


(4) 从 保存 在 临时 文件 中 的 提交 列表 中 ， 将 提交 逐一 按 顺 序 重新 
是 交 到 重 置 之 后 的 分 文 上 。 


(5) 如 果 遇 到 提交 已 经 在 分 支 中 包含 ， 则 跳 过 该 提交 。 


(6) 如果 在 提交 过 程 遇 到 冲突 ， 则 变 基 过 程 暂停 。 用 户 解决 冲突 
后 ， 执 行 git rebase--continue 继 续 变 基 操 作 。 或 者 执行 git rebase--skip 跳 
过 此 提交 。 或 者 执行 git rebase--abort 就 此 终止 变 基 操作 切换 到 变 基 前 
的 分 文 上 。 


很 显然 为 了 执行 将 E 和 F 提 交 跳 过 提交 D,，“ 怒 接 ” 到 提交 CC 上。 可 以 
如 此 执行 变 基 命令 : 


$git rebase--onto C EAF 


因为 EA 等 价 于 D， 并 且 F 和 当前 HEAD 的 指向 相同 ， 因 此 可 以 这 样 
操作 : 


$git rebase--onto C D 


有 了 对 变 基 命令 的 理解 ， 束 可 以 开始 新 的 “ 回 到 未 来 "之 旅 了 。 


确认 舞台 已 经 布置 完毕 


$git status-s-b 

##master 

$git log--oneline--decorate-6 

b6fobOa(HEAD, tag:F,master )modify hello.h 
48456ab(tag:E)add hello.h 
3488f2c(tag:D)move.gitignore outside also works. 
b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 


1. 现 在 演出 第 一 幕 : 干掉 坏蛋 D 


(1) 执行 变 基 操作 。 


因为 下 面 的 变 基 操 命令 行使 用 了 参数 F。F 是 一 个 里 程 碑 指 同 一 个 
提交 ， 而 非 master， 会 导致 后 面 变 其 完成 后 还 需要 对 master 分 支 执行 重 
置 。 在 第 二 幕 中 使 用 分 文 master 作 为 参数 ， 会 发 现 省 事 不 少 。 


$git rebase--onto C EAF 

First,rewinding head to replay your work on top of it... 
Applying:add hello.h 

Applying:modify hello.h 


(2) 最 后 一 步 必 需 的 操作 ， 束 是 要 将 master 分 支 指向 变 基 后 的 提 


下 面 的 切换 操作 使 用 了 reflog 的 语法 ， 即 HEAD@{1} 相 当 于 切换 
回 master 分 支 前 的 HEAD 指 向 ， 即 3360440 。 


$git checkout master 

Previous HEAD position was 3360440...modify hello.h 
Switched to branch 'master' 

$git reset--hard HEAD@{1} 

HEAD is now at 3360440 modify hello.h 


$git 1og--oneline--decorate-6 
3360440(HEAD, master )modify hello.h 

1ef3803 add hello.h 

b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 

63992f0 restore file:welcome.txt 


2. 尹 布 拉 上 ， 后 台 重 新 布景 


为 了 第 二 幕 能 够 顺利 演出 ， 需 要 将 master 分 文 重 新 置 回 到 提交 F 
上 。 执 行 下 面 的 操作 完成 < 重新 布景 ”。 


$git checkout master 

Already on 'master' 

$git reset--hard F 

HEAD is now at b6foboa modify hello.h 


布景 完毕 ， 大 和 幕 即 将 再 次 拉 开 。 


3. 现 在 演出 第 二 梨 : 坏蛋 D 被 感化 ， 融 入 社会 


(1) 执行 git checkout 命 令 ， 暂 时 将 HEAD 头 指针 切换 到 坏蛋 
切换 过 程 显 示 处 于 非 跟踪 状态 的 警告 ， 没 有 关系 ， 因 为 剧情 需 


$git checkout D 

Note:checking out 'D'. 

You are in 'detached HEAD' state.You can look around,make 
experimental 

changes and commit them,and you can discard any commits you make 
in this 

state without impacting any branches by performing another 
checkout. 

If you want to create a new branch to retain commits you 
create,you may 

do so(now or later)by using-b with the checkout command 
again.Example: 

git checkout-b new_branch_name 

HEAD is now at 3488f2c...move.gitignore outside also works. 


(2) 悔 棋 两 次 ， 以 便 将 C 和 D 融 合 。 


$git reset--soft HEADAA 


(3) 执行 提交 ， 提 交 说 明 重 用 C 提 交 的 提交 说 明 。 


$git commit-C C 

[detached HEAD 2d020b6]ignore object files. 

1 files changed,3 insertions(+),0 deletions(-) 
create mode 100644.gitignore 


(4) 记 住 这 个 提交 ID: 2d020b6 。 


用 里 程 碑 是 记忆 提交 ID 的 最 好 方法 : 


$git tag newbase 


$git rev-parse newbase 
2d020b62034b7a433f80396118bc3f66a60f296f 


(5) 执行 变 基 操 作 ， 将 E 和 EF 提 交 “ 嫁 接 ” 到 newbase 上 。 


下 面 的 变 基 操 命 令 行 没有 像 之 前 的 操作 那样 使 用 参数 F， 而 是 使 
用 分 文 master。 所 以 接 下 来 的 变 基 操作 会 直接 修改 master 分 文 ， 而 无 须 
再 对 master 进 行 重 置 操作 。 
$git rebase--onto newbase E^master 
First,rewinding head to replay your work on top of it... 


Applying:add hello.h 
Applying:modify hello.h 


(6) 看 看 提交 日 志 ， 看 到 提交 C 和 提交 D 都 不 见 了 ， 代 之 以 融合 


后 的 提交 newbase。 


还 可 以 看 到 最 新 的 提交 除了 和 HEAD 的 指向 一 致 ， 也 和 master 分 文 
的 指 同 一 致 。 


$git log--oneline--decorate-6 

2495dc1(HEAD,master )modify hello.h 

6349328 add hello.h 

2d020b6(tag:newbase)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 

63992f0 restore file:welcome.txt 


(7) 当前 的 确 已 经 在 master 分 支 上 了 ， 操 作 全 部 完成 。 


$git branch 


*master 


(8) 清理 一 下 ， 然 后 收工 。 


前 面 的 操作 中 为 了 方便 创建 了 标识 提交 的 新 里 程 碑 newbase， 
里 程 碑 现在 没有 什么 用 处 了 ， 删 除 吧 。 


xt 


$git tag-d newbase 
Deleted tag 'newbase' (was 2d020b6 ) 


4. 别 起 了 后 台 的 重新 布景 


为 了 接 下 来 的 时 间 旅 行 三 能 够 顺利 开始 ， 需 要 重新 布景 ， 将 
master 分 文 重新 置 回 到 提交 FE 上 。 


$git checkout master 

Already on 'master' 

$git reset--hard F 

HEAD is now at b6foboa modify hello.h 


ss 


123.3- 肝 间 洲 行 三 


《 回 到 未 来 》 第 三 集 ， 成 了 铁匠 的 布衣 博士 手工 打造 了 可 以 时 光 
旅行 的 飞行 火车 ， 使 用 蒸汽 作为 动力 。 这 球 时 间 旅 行 火车 更 大 、 更 安 
全 、 更 舒适 ， 适 合 一 家 四 口外 加 宠物 的 时 空 旅行 。 与 之 对 应 本 次 实践 
也 将 永 用 "了 于 二 们 信和 广 让 式 全 时 5 


交互 式 变 基 故 是 在 上 一 市 介绍 的 变 基 命令 的 基础 上 ， 添 加 了 -i 参 
数 ， 在 变 基 的 时 候 进 入 一 个 交互 界面 。 使 用 了 交互 界面 的 变 基 操作 ， 
不 是 目 动 化 变 基 转换 为 手动 确认 那么 没有 技术 含量 ， 而 是 充满 了 魔 
法 。 


执行 交互 式 变 基 操 作 ， 会 将 <since>..<t 记 > 的 提交 悉数 罗列 在 
一 个 文件 中 ， 然 后 目 动 打开 一 个 编辑 紫 来 编辑 这 个 文件 。 可 以 通过 修 
改 文件 的 内 容 设 定 变 基 操 作 ， 实 现 删 除 提交 、 将 多 个 提交 压缩 为 一 个 
提交 、 更 改 提交 的 顺序 ， 以 及 更 改 历史 提交 的 提交 说 明 等 。 


例如 ， 下 面 的 界面 就 是 针对 当前 DEMO 版 本 库 执 行 的 交互 式 变 基 
时 编辑 器 打开 的 文件 : 


pick b3af728 ignore object files. 

pick 3488f2c move.gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 

#Rebase d71ce92..b6foboa onto d71ce92 


# 

#Commands : 

#p,pick=use commit 

#r,reword=use commit,but edit the commit message 

#e,edit=use commit,but stop for amending 

#s, squash=use commit,but meld into previous commit 

#f, fixup=like "squash",but discard this commit's log message 

#x<cmd>,exec<cmd>=RUN a shell command<cmd> ,and stop if it 
fails 

# 

#If you remove a line here THAT COMMIT WILL BE LOST. 

#However,if you remove everything,the rebase will be aborted. 


从 该 文件 中 可 以 看 出 : 
开头 的 四 行 由 上 到 下 依次 对 应 于 提交 C、D、E、F。 


前 四 行 默认 的 动作 都 是 pick， 即 应 用 此 提交 。 


参考 文件 中 的 注释 ， 可 以 通过 修改 动作 名 称 ， 在 变 基 的 时 候 执 行 


特定 操作 。 


动作 reword， 或 者 简写 为 r。 在 变 基 时 会 应 用 此 提交 ， 但 是 在 提交 
的 时 候 允 许 用 户 修改 提交 说 明 。 这 个 功能 在 Git 1.6.6 之 后 开始 提供 ， 对 
于 修改 历史 提交 的 提交 说 明 非 常 方 便 。 对 于 老 版 本 的 Git 没 有 reword 动 
作 ， 可 以 使 用 edit 动 作 。 


动作 edit， 或 者 简写 为 e。 也 会 在 变 基 时 应 用 此 提交 ， 但 是 会 在 应 
用 后 暂停 变 基 ， 提 示 用 户 使 用 git commit--amend 执 行 提 交 ， 以 便 对 提 
交 进 行 修 补 。 当 用 户 执行 git commit--amend 完 成 提交 后 ， 还 需要 执行 


git rebase--continue 继 续 变 基 操 作 。 用 户 在 变 基 和 暂停 状态 下 可 以 执行 多 
次 提交 ， 从 而 实现 把 一 个 提交 分 解 为 多 个 提交 。edit 动 作 非 常 强大 ， 对 
于 老 版 本 的 Git 没 有 reword 动 作 ， 可 以 使 用 edit 动 作 实现 相同 的 效果 。 


动作 squash， 或 者 简写 为 s。 该 提交 会 与 前 面 的 提交 压缩 为 一 个 。 


动作 fixup， 或 者 简写 为 f。 类 似 动 作 squash， 但 是 此 提交 的 提交 说 
明 被 于 弃 。 这 个 功能 在 Git 1.7.0 之 后 开始 提供 ， 老 版 本 的 Git 还 是 使 用 
squash 动 作 吧 。 


可 以 通过 修改 变 基 任务 文件 中 各 个 提交 的 先后 顺序 ， 进 而 改变 最 
终 变 基 后 提交 的 先后 顺序 。 


可 以 修改 变 基 任务 文件 ， 删 除 包 含 相应 提交 的 行 ， 这 样 该 提交 整 
不 会 被 应 用 ， 进 而 在 变 基 后 的 提交 中 被 删除 。 


有 了 对 交互 式 变 基 命令 的 理解 ， 束 可 以 开始 新 的 “ 回 到 未 来 ”之 旅 
了 。 


确认 舞台 已 经 布置 完毕 。 


$git status-s-b 

##master 

$git log--oneline--decorate-6 

b6fobOa(HEAD, tag:F,master )modify hello.h 
48456ab(tag:E)add hello.h 
3488f2c(tag:D)move.gitignore outside also works. 
b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 


cO24f34(tag:A)README is from welcome.txt. 


1. 现 在 演出 第 一 幕 : 干掉 坏蛋 D 


(1) 执行 交互 式 变 基 操作 。 


$git rebase-i DA^ 


(2) 自动 用 编辑 器 修改 文件 。 文 件 内 容 如 下 : 


pick 3488f2c move.gitignore outside also works. 

pick 48456ab add hello.h 

pick b6foboa modify hello.h 

#Rebase b3af728..b6foboa onto b3af728 

# 

#Commands : 

#p, pick=use commit 

#r,reword=use commit,but edit the commit message 

#e,edit=use commit,but stop for amending 

#s, squash=use commit,but meld into previous commit 

#f, fixup=like "squash",but discard this commit's log message 

#x<cmd>,exec<cmd>=RUN a shell command<cmd> ,and stop if it 
fails 

# 

#If you remove a line here THAT COMMIT WILL BE LOST. 

#However,if you remove everything,the rebase will be aborted. 

# 


(3) 将 第 一 行 删除 ， 使 得 上 面 的 文件 看 起 来 像 是 这 样 (省 上 略 井 号 
开始 的 注释 ) 


pick 48456ab add hello.h 
pick b6foboa modify hello.h 


(4) 保存 退出 。 
变 基 自 动 开始 ， 即 刻 完成 。 
显示 下 面 的 内 容 : 


Successfully rebased and updated refs/heads/master. 


(5) 看 看 日 志 。 当 前 分 支 master 已 经 完成 变 基 ， 消 灭 了 “坏蛋 
D”° 


$git 1og--oneline--decorate-6 

78e5133(HEAD,master )modify hello.h 

11eea7e add hello.h 

b3af728(tag:C)ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 

63992f0 restore file:welcome.txt 


2. 尹 布 拉 上 ， 后 台 重 狐 布 景 


为 了 第 二 才能 够 顺利 演出 ， 需 要 将 master 分 文 重 新 置 回 到 提交 F 
上 。 执 行 下 面 的 操作 完成 “重新 布景 ”。 


$git checkout master 

Already on 'master' 

$git reset--hard F 

HEAD is now at b6foboa modify hello.h 


景 完 毕 ， 大 幕 即 将 再 次 拉 开 。 


3. 现 在 演出 第 二 医 : 坏蛋 D 被 感化 ， 融 入 社会 


(1) 同样 执行 交互 式 变 基 操作 ， 不 过 因为 要 将 C 和 D 压 缩 为 一 
个 ， 因 此 变 基 从 C 的 父 提交 开始 。 


$git rebase-i CA^ 


(2) 自动 用 编辑 器 修改 文件 。 文 件 内 容 如 下 (忽略 井 号 开始 的 注 
释 ) : 
pick b3af728 ignore object files. 
pick 3488f2c move.gitignore outside also works. 


pick 48456ab add hello.h 
pick b6foboa modify hello.h 


(3) 修改 第 二 行 (提交 D) ， 将 动作 由 pick 修 改 为 squash。 修 改 
后 的 内 容 如 下 : 


pick b3af728 ignore object files. 

squash 3488f2c move.gitignore outside also works. 
pick 48456ab add hello.h 

pick b6foboa modify hello.h 


(4) 保存 退出 。 自 动 开 始 变 基 操作 ， 在 执行 到 squash 命 令 设 定 的 
提交 时 ， 进 入 提交 前 的 日 志 编 辑 状 态 。 


显示 的 竺 编辑 日 志 如 下 。 很 明显 C 和 DD 的 提交 说 明显 示 在 了 一 起 。 


#This is a combination of 2 commits. 


#The first commit's message is: 
ignore object files. 

#This is the 2nd commit message: 
move.gitignore outside also works. 


(5) 保存 退出 ， 即 完成 squash 动 作 标 识 的 提交 合并 及 后 续 变 基 操 
1 


看 看 提交 日 志 ， 看 到 提交 C 和 提交 D 都 不 见 了 ， 代 之 以 一 个 融合 后 
的 提交 出 现 。 


$git log--oneline--decorate-6 
coc2a1la(HEAD,master )modify hello.h 

cle8b66 add hello.h 

db512c0 ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 

63992f0 restore file:welcome.txt 


(6) 可 以 看 到 融合 C 和 D 的 提交 日 志 实 际 上 是 两 者 日 志 的 融合 。 
在 前 面 单行 显示 的 日 志 中 看 不 出 来 。 


$git cat-file-p HEADA^ 人 ^ 

tree 00239a5d0daf9824a23cbf104d30af66af984e27 

parent d71ce9255b3b08c718810e4e31760198dd6da243 

author Jiang Xin<jiangxin@ossxp.com>1291720899+0800 
committer Jiang Xin<jiangxin@ossxp.com>1292153393+0800 
ignore object files. 

move.gitignore outside also works. 


时 光 旅 行 结 束 了 ， 多 么 神奇 的 Git 啊 。 


1 相关 下 历史 


历史 有 的 时 候 会 成 为 负担 。 例 如 一 个 人 使 用 的 版 本 库 有 一 天 需要 
作为 公共 版 本 库 多 人 共 译 ， 最 早 的 历史 可 能 不 布 望 或 者 没有 必要 继续 
保持 存在 ， 需 要 一 个 抛弃 部 分 早期 历史 提交 的 精简 的 版 本 库 以 用 于 和 
他 人 共 至 。 再 比如 用 Git 做 文件 备份 ， 不 希望 备份 的 版 本 过 多 而 导致 不 
必要 的 磁盘 空间 占用 ， 同 样 会 有 精 价 版 本 的 需要 : 只 你 留 最 近 的 100 次 
提交 ， 抛 弃 之 前 的 历史 提交 。 那 么 应 该 如 何 操 作 呢 ? 


使 用 交互 式 变 基 当 然 可 以 完成 这 样 的 任务 ， 但 是 如 采 历 史 版 本 库 
有 成 百 上 千 个 ， 把 成 百 上 千 个 版 本 的 变 基 动作 中 有 pick 的 修改 为 fixup 
可 真 的 很 费事 ， 实 际 上 Git 有 更 稍 便 的 方法 。 


现在 DEMO 版 本 库 有 如 下 的 提交 记录 : 


$git 1og--oneline--decorate 
coc2a1la(HEAD,master )modify hello.h 

cle8b66 add hello.h 

db512c0 ignore object files. 
d7ice92(tag:hello_1.0,tag:B)Hello world initialized. 
cO24f34(tag:A)README is from welcome.txt. 
63992f0 restore file:welcome.txt 

7161977 delete trash files.(using:git add-u) 
2b31c1i9(tag:old practice)Merge commit 'acc2f69' 
acc2f69 commit in detached HEAD mode. 

4902dc3 does master follow this new commit? 
e695606 which version checked in? 

ao0c641e who does commit? 

9e8a761 initialized. 


如 果 和 希望 把 里 程 碑 A_ (c024f34) 之 前 的 历史 提交 全 部 清除 ， 可 以 
这 样 操作 ， 基 于 里 程 碑 A 对 应 的 提交 构造 一 个 根 提交 ( 即 没 有 父 提交 
的 提交 ) ， 然 后 再 将 master 分 支 在 里 程 碑 A 之 后 的 提交 变 基 到 新 的 根 提 
区 上 ， 实 现 对 历史 提交 的 请 除 。 


由 里 程 碑 A 对 应 的 提交 构造 出 一 个 根 提交 人 至少 有 两 种 方法 。 
种 方法 是 使 用 git commit-tree 命 令 ， 可 以 进行 如 下 操作 。 


(1) 查看 里 程 碑 A 指向 的 目录 树 。 
用 AA^{tree} 语 法 访问 里 程 碑 A 对 应 的 目 隶 树 。 


$git cat-file-p A^{tree} 
100644 blob 51dbfd25a804c30e9d8dc441740452534de8264b README 


(2) 使 用 git commit-tree 命 令 直 接 从 该 目录 树 创建 提交 。 


$echo "Commit from tree of tag A."|git commit-tree A^{tree} 
8f7f94ba6a9d94ecc1c223aa4b311670599e1f86 


(3) 命令 git commit-tree 的 输出 是 一 个 提交 的 SHA1 哈 希 值 。 查 看 
这 个 提交 。 会 发 现 这 个 提交 没有 历史 提交 ， 是 我 们 需要 的 根 提交 。 


$git 1og--pretty=raw 8f7f94b 

commit 8f7f94ba6a9d94ecc1c223aa4b311670599e1f86 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

author Jiang Xin<JjiangxinQ@ossxp.com>1292221037+0800 
committer Jiang Xin<jiangxin@ossxp.com>1292221037+0800 
Commit from tree of tag A. 


另外 一 个 方法 是 使 用 git hash-object 命 令 ， 从 里 程 碑 A 指 同 的 提交 
建立 一 个 根据 交 。 可 以 进行 如 下 操作 。 


(1) 查看 里 程 碑 A 指 向 的 提交 。 


用 A^0 语 法 访问 里 程 碑 A 对 应 的 提交 。 


$git cat-file commit AAO 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

parent 63992f05a72865754809cc0772a9e1fbf134e380 

author Jiang Xin<jiangxin@ossxp.com>1291704602+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291704602+0800 
README is from welcome.txt. 


(2) 将 上 面 的 输出 (里 程 碑 A 指 向 的 提交 ) 过 滤 掉 以 parent 开 头 
的 行 ， 并 将 结 采 保存 到 一 个 文件 中 。 


$git cat-file commit A^0|sed-e '/^parent/d'>tmpfile 


(3) 运行 git hash-object 命 令 ， 将 文件 tmpfile 作 为 一 个 commit 对 象 
写 入 对 象 库 。 


$git hash-object-t commit-w--tmpfile 
4d387fd42a023aadcf0702907b848444e8c4429c 


(4) 上 面 执行 git hash-object 命 令 的 输出 结果 就 是 写 入 Git 对 象 库 
中 的 新 的 提交 对 象 ID。 查 看 会 发 现 该 提交 就 是 我 们 需要 的 新 的 根据 
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$git 1Log--pretty=raw 4d387fd 

commit 4d387fd42a023aadcf0702907b848444e8c4429c 

tree 3f9b9459e9c0532ff6e3c16c3098c947d55fba41 

author Jiang Xin<jiangxin@ossxp.com>1291704602+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291704602+0800 
README is from welcome.txt. 


无 论 采 用 哪 种 方法 创建 了 者 的 根据 交 后 ， 束 可 以 执行 变 基 操作 ， 
将 master 分 文 在 里 程 碑 A 之 后 的 提交 变 基 到 新 的 根 提交 上 。 下 面 的 示例 
选择 第 一 种 方法 创建 的 根 所 区 8f7f94b 。 


(1) 执行 变 基 ， 将 master 分 文 里 程 碑 A 之 后 的 提交 全 部 迁移 到 根 
提交 8fzf94b 上 。 


$git rebase--onto 8f7f94b A master 

First,rewinding head to replay your work on top of it... 
Applying:Hello world initialized. 

Applying:ignore object files. 

Applying:add hello.h 

Applying:modify hello.h 


(2) 查看 日 志 看 到 当前 master 分 支 的 历史 已 经 精简 了 。 


$git lo0g--oneline--decorate 
2584639(HEAD, master )modify hello.h 
30fe8b3 add hello.h 

4dd8a65 ignore object files. 


Sf2cael Hello Worlad initialized. 
Bf7f94b Commit fxrom tree of tag A, 


使 用 图 形 工具 查看 提交 历史 ， 会 看 到 两 棵 树 ， 如 图 12-7 所 示 : 


最 上 面 的 一 棵 树 是 刚刚 


通过 变 基 栅 弃 了 大 部 分 历史 提交 的 新 的 master 分 支 ， 下 面 的 一 株 树 则 是 变 基 前 的 提交 形成 
的 。 下面 的 一 棵 树 之 所 以 还 能 够 看 到 ， 或 者 说 还 没有 从 版 本 库 中 彻底 清除 ， 基 因为 有 部 分 提 
交 仍 带 有 里 程 碑 标签 。 


Graph 


: Short 
er modify hello h 


add hello h 
ignore object fles, 

Hello world initialized. 
Comrng from tree of tag A- 


move gitignore outside atso works. 


object files. 
Helo world initialized 


reastore fe” welcome bt 
delete trash files. (Using: git add -由 


ES WP on master: 2b31c19 Merge commit "acc2f69) 
index on master: 2b31c19 Merge comrrit ‘acc2169 


Big oracticel Merge commit “acc2t69 
commit in detached HEAD mode, 


does master {olow this new commit? 


Which version checked im? 
who does commit? 
initialized. 


图 12-7 丢弃 历史 后 的 提交 分 支 医 


Author Date 


-. 10-12-12 PM12:11 
.. 10-12-7 PM7:39 
,, 10.12:7 PM7:21 
.. 10-12-7 PM6:33 
. 10-12-13PM2:17 


10.12.12 PM12:;11 


,. 10-12-7 PM7:39 
.. 10-12-7 PM7134 
.. 10-12-7 PM7;21 
, 10.12.7 PM6:33 
.. 10-12-7 PM2:50 


10-12-7 PM2: 32 


. 10-12-7 PM2:02 
，10-12-7 AM11:53 
，10.12-7 AM11:53 
. 10-12-5 PM3:51 


10-12-5 PM3:43 


. 10.12-4 PM12:13 
-.. 10-11-29 PM5:23 
.30-11-29 AM11:00 

10.11.28 PM12:48 


12.5“ 反 转 提 交 


前 面 介 绍 的 操作 都 涉及 对 历史 的 修改 ， 这 对 于 一 个 人 使 用 Git 没有 问题 ， 但 是 如 果 多 人 
协同 就 会 有 问题 了 。 多 人 协同 使 用 Git， 在 本 地 版 本 库 做 的 提交 会 通过 多 人 之 间 的 交互 成 为 
他 人 版 本 库 的 一 部 分 ， 更 改 历史 操作 只 能 是 针对 自己 的 版 本 库 ， 而 无 法 去 修改 他 人 的 版 本 
库 ， 正 所 谓 “ 覆 水 难 收 ”。 在 这 种 人 情况 下 要 想 修正 一 个 错误 历史 提交 的 正确 做 法 是 反 转 提交 ， 
即 重新 做 一 次 新 的 提交 ， 相当 于 用 错误 的 历史 提交 的 反 向 提交 ， 来 修正 错误 的 历史 提交 ， 

Git 反 向 提交 命令 是 ; git revert， 下 面 在 DEMO 版 本 库 中 实践 一 下 。 注意 : 
Subversion 的 用 户 不 要 想当然 地 和 svn revert 命令 对 应 ， 这 两 个 版 本 控制 系统 中 revert 命 
令 的 功能 完全 不 相干 。 

当前 DEMO 版 本 库 最 新 的 提交 包含 如 下 改动 ; 


§ git show HEAD 

commit 25846394defelseabl03bhbo2efdaabSsed4éccadc22 
Author: Jiang Xin <jiangxin8ossxp.,com> 

Dare: Sun Der 12 12:11:00 2010 sOANC 


modify heilo.h 


diff -~qit a/README b/README 


index 51dbfd2. .ceaf01b 100644 
---a/README 

+++b/README 

QQ-1, 3+1, 4@@ 

Hello. 

Nice to meet you. 

Bye-Bye. 

+Wait... 

diff--git a/src/hello.h b/src/hello.h 
index 0043c3b..6e482c6 100644 
---a/s r c/hello.h 
+++b/src/hello.h 

QQ@-1+1, 2@@ 

/*test*/ 

+/*end*/ 


在 不 改变 这 个 提交 的 前 提 下 撤销 对 其 的 修改 ， 就 需要 用 到 git 
revert 反 转 提交 。 


$git revert HEAD 


运行 该 命令 相当 于 将 HEAD 提 交 反 癌 再 提交 一 次 ， 在 提交 说 明 编 
辑 状 态 下 和 暂停， 显示 如 下 (注释 行 被 忽略 ) 


Revert "modify hello.h" 
This reverts commit 25846394defel6eab103b92efdaab5e46cc3dc22. 


可 以 在 编辑 器 中 修改 提交 说 明 ， 提 交 说 明 编 辑 完毕 保存 退出 则 完 
成 反 转 提交 。 查 看 提交 日 志 可 以 看 到 新 的 提交 相当 于 所 撤销 提交 的 反 


$git 1og--Stat-2 

commit 6e6753add1601c4efa7857ab4c5b245e0e161314 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Mon Dec 13 15:19:12 2010+0800 

Revert "modify hello.h" 

This reverts commit 25846394defe16eab103b92efdaab5e46cc3dc22 
README |1- 

src/hello.h|1- 

2 files changed,0 insertions(+),2 deletions(-) 
commit 25846394defe16eab103b92efdaab5e46cc3dc22 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Sun Dec 12 12:11:00 2010+0800 

modify hello.h 

README | 1+ 

src/hello.h|1+ 

2 files changed,2 insertions(+),0 deletions(-) 


第 13 章 ”Git 克隆 


到 现在 为 止 ， 大 家 已 经 领略 到 Git 的 灵活 性 和 健壮 性 。Git 可 以 通过 重 置 随意 撤销 提交 ， 
可 以 通过 变 基 操作 更 改 历 中， 可 以 随意 重组 提交 ， 还 可 以 通过 reflog 的 记录 纠正 错误 的 操 
作 。 但 是 再 健壮 的 版 本 库 设计 ， 也 抵挡 不 了 存储 介质 的 崩溃 。 还 有 一 点 就 是 不 要 忘 了 Git 版 
本 库 是 躲 在 工作 区 根 目 录 下 的 .git 目录 中 ， 如 果 忘 了 这 一 点 直接 删除 工作 区 ， 就 会 把 版 本 
库 也 同时 删 掉 ， 斐 剧 就 此 发 生 : 

“不 要 把 鸡蛋 装 在 一 个 篮子 里 ”是 颠 扑 不 破 的 安全 法 则 。 

在 本 章 会 学 习 到 如 何 使 用 git clone 命令 建立 版 本 库 克 降 ， 以 及 如 何 使 用 git push 
和 9it pull 命令 实现 克隆 之 间 的 同步 。 


13.1 鸡 条 不 装 在 一 个 篮子 里 


Git 的 版 本 库 目 录 和 工作 区 在 一 起 ， 因 此 存在 一 损 俱 损 的 问题 ， 即 如 果 删 除 一 个 项 目的 
工作 区 ， 同 时 也 会 把 这 个 项 目的 版 本 库 柚 除 掉 。 一 个 项 目 仅 在 一 个 工作 区 中 维护 太 和 危险 了 ， 
如 果 有 两 个 工作 区 就 会 好 很 多 。 


git clone 


zm : PUSH EL 
®@: PULL 加 : PUSH 


图 13-1 克隆 版 本 库 关 系 图 


图 13-1 中 一 个 项 目 使 用 了 两 个 版 本 库 进行 维护 ， 两 个 版 本 库 之 间 通 过 PULL 和 /或 
PUSH 操作 实现 同步 : 

口 版 本 库 A 通过 克隆 操作 创建 克隆 版 本 库 B。 

口 版 本 库 A 可 以 通过 PUSH 推送》 操作 ， 将 新 提交 传递 给 版 本 库 B。 

口 版 本 库 A 可 以 通过 PULL ( 拉 回 ) 操作 ， 将 版 本 库 B 中 的 新 提交 拉 回 到 自身 (A)。 

口 版 本 库 B 可 以 通过 PULL ( 拉 回 ) 操作 ， 将 版 本 库 A 中 的 新 提交 拉 回 到 自身 〈B): 

口 版 本 库 B 可 以 通过 PUSH 推送) 操作 ， 将 新 提交 传递 给 版 本 库 A。 

Git 使 用 git clone 命令 实现 版 本 库 克 隆 ， 主 要 有 如 下 三 种 用 法 : 


用 法 1: qit cilone <repository> <directory> 

用 法 2: qit clone --bare <repository> «directory.qit> 

用 法 3: qit CIone --mirror «repository> «directory.qit> 

这 三 种 用 法 的 区 别 如 下 : 

口 用 法 1 将 <repository> 指向 的 版 本 库 创 建 一 个 克隆 到 <directory> 目录 。 目 录 
<directory> 相当 于 克隆 版 本 库 的 工作 区 ， 文 件 都 会 检 出 ， 版 本 库 位 于 工作 区 下 
的 .git 目录 中 . 

口 用 法 2 和 用 法 3 创建 的 克 降 版 本 库 都 不 包含 工作 区 ， 直 接 就 是 版 本 库 的 内 容 ， 这 样 的 
版 本 库 称 为 裸 版 本 库 。 一 般 约 定 俗 成 裸 版 本 库 的 目录 名 以 .git 为 后 织 ， 所 以 上 面 示 
例 中 将 克隆 出 来 的 裸 版 本 库 目 录 名 写作 <directory.git>。 

口 用 法 3 区别 于 用 法 2 之 处 在 于 用 法 3 克隆 出 来 的 裸 版 本 对 上 游 版 本 库 进行 了 注册 ， 这 
样 可 以 在 裸 版 本 库 中 使 用 9it fetch 命令 和 上 游 版 本 库 进行 持续 同步 ， 

口 用 法 3 只 在 1.6.0 或 更 新 版 本 的 Git 中 才 提 供 。 

Git 的 PUSH 和 PULL 命令 的 用 法 相似 ， 使 用 下 面 的 语法 : 


git push [<remote-repos> 【<refspec>] 
git pull [<remote-repos> [<refspec>], 


其 中 方 括号 的 含义 是 参数 可 以 省 略 ，<remote-zepos> 是 远程 版 本 库 的 地 址 或 名 称 ， 
<refspec> 是 引用 表达 式 ， 暂 时 理解 为 引用 即 可 。 后 面 的 章节 再 具体 介绍 PUSH 和 PULL 
命令 的 细节 。 

下 面 就 通过 不 同 的 Git 命令 组 合 ， 掌 所 版 本 库 克 隆 和 镜像 的 技巧 。 


13.2 ”对 等 工作 区 


不 使 用 --hare 或 --mirror 创建 出 来 的 克隆 包含 工作 区 ， 这 样 就 会 产生 两 个 包含 工 
作 区 的 版 本 库 。 这 两 个 版 本 库 是 对 等 的 ， 如 图 13-2 所 示 


图 13-2 带 工作 区 的 对 等 版 本 库 


这 两 个 工作 区 本 质 上 没有 区 别 ， 但 是 往往 提交 是 在 一 个 版 本 
(A) 中 进行 的 ， 另 外 一 个 (B) 作为 备份 。 对 于 这 种 对 等 工作 区 模 
式 ， 版 本 库 的 同步 只 有 一 种 可 行 的 操作 模式 ， 就 是 备份 库 (B) 执行 
git pull 命 令 从 源 版 本 库 (A) 中 拉 回 新 的 提交 实现 版 本 库 同步 。 为 什 
么 不 能 从 版 本 库 A 疝 版 本 库 B 执 行 git push 推 送 操作 呢 ? 看 看 下 面 的 操 
作 = 


执行 克隆 命令 ， 将 版 本 库 /path/to/my/workspace/demo 兄 隆 


到 /path/to/my/workspace/demo-backup。 


$git clone/path/to/my/workspace/demo/path/to/my/workspace/demo- 
backup 

Cloning into/path/to/my/workspace/demo-backup... 

done. 


进入 demo 版 本 库 ， 生 成 一 些 测试 提交 (使 用 --allow-empty 参 数 可 


$cd/path/to/my/workspace/demo/ 

$git commit--allow-empty-m "sync test 1" 
[master 790e72alsync test 1 

$git commit--allow-empty-m "sync test 2" 
[master f86b7bf]jsync test 2 


能 够 在 demo 版 本 库 疝 demo-backup 版 本 库 执行 PUSH 操 作 吗 ? 执行 
一 下 git push 看 一 看 。 


$git push/path/to/my/workspace/demo-backup 

Counting objects:2, done. 

Delta compression using up to 2 threads. 

Compressing objects:100%(2/2),done. 

Writing objects:100%(2/2),274 bytes, done. 

Total 2(delta 1),reused 0O(delta 0) 

Unpacking objects:100%(2/2),done. 

remote:error:refusing to update checked out 
branch:refs/heads/master 

remote:error:By default,updating the current branch in a non- 
bare repository 

remote:error:is denied,because it will make the index and work 
tree inconsistent 

remote:error:with what you pushed,and will require 'git reset-- 
hard' to match 

remote:error:the work tree to HEAD. 

remote:error: 

remote:error:You can set 'receive.denyCurrentBranch' 
configuration variable to 

remote:error:'ignore' or ‘'warn' in the remote repository to 
allow pushing into 

remote:error:its current branch; however,this is not recommended 
unless you 

remote:error;arranged to update its work tree to match what you 
pushed in some 

remote:error:other way. 

remote:error: 


remote:error:To squelch this message and still keep the default 
behaviour, set 

remote:error:'receive.denyCurrentBranch' configuration variable 
to "refuse ' ， 

To/path/to/my/workspace/demo-backup 

![remote rejectedlmaster->master(branch is currently checked 
out) 

error:failed to push some refs to '/path/to/my/workspace/demo- 
backup' 


翻译 成 中 文 : 


$git push/path/to/my/workspace/demo-backup 


对 方 说 : 错 了 : 
拒绝 更 新 已 检 出 的 分 支 refs/heads/master。 

默认 更 新 非 裸 版 本 库 的 当前 分 支 是 不 被 允许 的 ,因为 这 将 会 导致 

暂 存 区 和 工作 区 与 你 推送 至 版 本 库 的 新 提交 不 一 致 。 这 太古 怪 了 。 

如 果 您 一 意 孤 行 , 也 不 是 不 允许 ,但 是 你 需要 为 我 设置 如 下 参数 : 
receive.denyCurrentBranch=ignore|warn 
ll/path/to/my/workspace/demo-backup 

! [对方 拒绝 ]Jmaster- >master( 分 支 当 前 已 检 出 ) 

错误 :部 分 引用 的 推送 失败 了 ,至 '/path/to/my/workspace/demo-backup' 


从 错误 输出 中 可 以 看 出 ， 虽 然 可 以 改变 Git 的 默认 行为 ， 允 许 向 工 
作 区 推送 已 经 检 出 的 分 文 ， 但 是 这 么 做 实在 不 高 明 。 


为 了 实现 同步 ， 需 要 进入 到 备份 版 本 库 中 ， 执 行 git pull 命 令 。 


$git pull 
From/path/to/my/workspace/demo 
6e6753a..f86b7bf master->origin/master 
Updating 6e6753a..f86b7bf 

Fast-forward 


在 demo-backup 版 本 库 中 得 看 提交 日 志 ， 可 以 看 到 在 demo 版 本 库 
中 的 狐 提 区 已 经 被 拉 回 到 demo-backup 版 本 库 中 。 
$git 1og--oneline-2 


f86b7bf Sync test 2 
790e72a Sync test 1 


为 什么 执行 git pull 命 令 没 有 像 执 行 git push 命 令 那 样 提供 那么 多 的 
参数 呢 ? 这 是 因为 在 执行 git clone 探 作 后 ， 克 隆 出 来 的 demo-backup 版 
本 库 中 对 源 版 本 库 (上 游 版 本 库 ) 进行 了 注册 ， 所 以 在 demo-backup 版 
本 库 中 执行 拉 回 操作 ， 无 须 设置 上 游 版 本 库 的 地 址 。 


在 demo-backup 版 本 库 中 可 以 使 用 下 面 的 命令 查看 对 上 游 版 本 库 的 
注册 信息 : 


$cd/path/to/my/workspace/demo-backup 
$git remote-v 
origin/path/to/my/workspace/demo(fetch) 
origin/path/to/my/workspace/demo(push) 


实际 上 ， 注 册 上 游 远 程 版 本 库 的 奥秘 都 在 Git 的 配置 文件 中 〈 略 去 
无 关 的 何 ) 


$cat/path/to/my/workspace/demo-backup/ .git/config 


[remote "origin"] 
fetch=+refs/heads/*:refs/remotes/origin/* 
url=/path/to/my/workspace/demo 

[branch "master"] 

remote=origin 


merge = refs/heads/master 


关于 配置 文件 [remotel] 小 节 和 [branch] 小 节 的 奥秘 将 在 第 3 篇 第 19 章 中 予以 介绍 


13.3 ”克隆 生成 裸 版 本 库 


上 一 节 在 对 等 工作 区 模式 下 ， 工 作 区 之 间 执 行 推送 ， 可 能 会 引发 大 段 的 错误 输出 ， 如 果 
采用 裸 版 本 库 则 没有 相应 的 问题 。 这 是 因为 裸 版 本 库 没 有 工作 区 。 设 有 工作 区 还 有 一 个 好 处 
就 是 空间 占用 会 更 小 . 


git clone --bare 


CEE 


| git push 


A B.git 
13-3 ”从 版 本 库 中 克隆 禄 版 本 座 


如 图 13-3 所 示 ， 使 用 --bare 参数 将 demo 版 本 库 殉 降 到 /path/to/repos/demo, 
9it， 然 后 就 可 以 从 demo 版 本 库 向 克隆 的 裸 版 本 库 执行 推送 操作 了 -《〈 为 了 说 明 方便 ， 使 用 
了 /Path/to/repos/ 作为 Git 裸 版 本 的 根 路 径 ， 在 后 面 的 章节 中 这 个 目录 也 将 作为 Git 服 
务 器 端 版 本 库 的 根 路 径 。 可 以 在 磁盘 中 以 root 账户 创建 该 路 径 并 设置 正确 的 权限 .) 

$ git clone --bare /path/to/my/workspace/demo /path/to/repos/demo.git 


Cloning into bare repository /path/to/repos/demo.9git... 
done. 


克隆 出 来 的 /path/to/repos/demo .git 目录 就 是 版 本 库 目 录 ， 不 包含 工作 区 。 
口 看 看 /path/to/repos/demo.git 目录 的 内 容 。 


ss ls -F /path/to/repos/demo.git 
branches/ confiq description HEAD hooks/ info/ obiects/ packed-refs refs/ 


口 还 可 以 看 到 demo.git 版 本 库 中 core .hare 的 配置 为 true。 


s git --git-dir=/path/to/repos/demo.git config core.bare 
true 

进入 demo 版 本 库 ， 生 成 一 些 测 试 提 交 . 

$§ cd /path/to/my/workspace/demo/ 

8 git commit -~-allow-empty -m "sync test 3" 

[master dab42b7] Sync test 3 

$ git commit -~~allow-empty -m "sync test 4" 


[master 0285742] sync test 4 


在 demo 版 本 库 向 demo-backup 版 本 库 执 行 PUSH 操作 ， 还 会 有 错误 吗 ? 
口 不 带 参 数 执行 9it push， 因 为 未 设 定 上 游 远程 版 本 库 ， 因 此 会 报错 : 


$§ git push 
fatal; No destination configured to push tc， 


口 在 执行 git push 时 使 用 /path/to/repos/demo .git 作为 参数 。 推 送 成 功 。 


ss git push /path/to/repos/demo .git 
Counting obiects: 2, done. 
Delta compression using up to 2 threads, 
Compressing cbiecta: 100% {2/2), done. 
Writing obiects: 100% {2/2), 275 bytes, done, 
Total 2 (delta 1), reused 0 (Gelta 0 
Unpacking obiects: 100% (2/2), done. 
To /path/to/repos/demo.qit 

EBEb7bE. .0285742 master -> master 


口 看 看 demo.git 版 本 库 ， 是 否 已 经 完成 了 同步 


ss git --git-dir=/path/to/repos/demo.git log --oneline -2 
0285742 Sync test 4 
d4b42b7 Sync test 3 


这 个 方式 实现 版 本 库 本 地 镜像 显然 是 更 好 的 方法 ， 因 为 可 以 直接 在 工作 区 修改 和 提交 ， 
然后 执行 9it Push 命令 实现 推送 。 稍 有 一 点 遗憾 的 是 推送 命令 还 需要 加 上 裸 版 本 库 的 路 
径 。 这 个 遗憾 在 第 3 篇 第 19 章 会 给 出 解决 方案 . 


13.4 ”创建 生成 梨 瞩 本 库 


裸 版 本 库 不 但 可 以 通过 克 降 的 方式 创建 ， 还 可 以 通过 git init 命令 以 初始 化 的 方式 创 
建 。 之 后 的 同步 方式 和 上 一 节 大 同 小 异 ， 如 图 13-4 所 示 ， 


git init --bare 


git push ~ = 


A B.git 


图 13-4 向 裸 版 本 库 推 送 


命令 git init 在 “第 4 章 Git 初 始 化 "一 章 束 已 经 用 到 了 ， 是 用 于 初始 化 
一 个 版 本 库 的 。 之 前 执行 git init 命 令 初 始 化 的 版 本 库 是 珊 工 作 区 的 ， 
如 何以 裸 版 本 库 的 方式 初始 化 一 个 版 本 库 呢 ?奥秘 丈 在 于 --bare 参 数 。 


下 面 的 命令 会 在 目录 /path/to/repos/demo-init.git 中 创建 一 个 空 的 裸 
版 本 库 。 


$git init--bare/path/to/repos/demo-init.git 
Initialized empty Git repository in/path/to/repos/demo-init.git/ 


创建 的 果真 是 裸 版 本 库 吗 ? 
看 看 /path/to/repos/demo-init.git 下 的 内 容 : 


$1s-F/path/to/repos/demo-init.git 


branches/config description HEAD hooks/info/objects/refs/ 


看 看 这 个 版 本 库 的 配置 core.bare 的 值 : 


$git--git-dir=/path/to/repos/demo-init.git config core.bare 
true 


可 是 空 版 本 库 没有 内 容 啊 ， 那 束 执 行 PUSH 操 作为 其 创建 内 容 
员 。 


$cd/path/to/my/workspace/demo 

$git push/path/to/repos/demo-init.git 

No refs in common and none specified;doing nothing. 

Perhaps you should specify a branch such as 'master ' ， 

fatal:The remote end hung up unexpectedly 

error:failed to push some refs to '/path/to/repos/demo-init.git' 


为 什么 出 错 了 ? 翻译 一 下 错误 输出 。 


$cd/path/to/my/workspace/demo 

$git push/path/to/repos/demo-init.git 

没有 指定 要 推送 的 引用 , 而 且 两 个 版 本 库 也 没有 共同 的 引用 。 
所 以 什么 也 没有 做 。 
可 能 您 需要 提供 要 推送 的 分 支 名 , 如 'master' 

严重 错误 :远程 操作 意外 终止 

错误 :部 分 引用 推送 失败 ,至 '/path/to/repos/demo-init.git' 


天 于 这 个 问题 的 详细 说 明 要 在 第 3 篇 第 19 革 “19.4 PUSH 和 PULL 操 
作 和 远程 版 本 库 ” 小 节 中 介绍 ， 这 里 先 说 一 个 省 略 版 : 
为 /path/to/repos/demo-init.git 版 本 库 刚 刚 初 始 化 完成 ， 还 没有 任何 提 
交 ， 更 不 要 说 分 支 了 。 当 执行 git push 命 令 时 ， 如 果 没 有 设 定 推 送 的 分 


支 ， 而 且 当 前 分 支 也 没有 注册 到 远程 的 某 个 分 支 ， 将 检查 远程 分 支 是 
否 有 和 本 地 相同 的 分 支 名 (如 master) ， 如 果 有 ， 则 推送 ， 否 则 报 


错 。 


所 以 需要 把 git push 命 令 写 得 再 完整 一 些 。 像 下 面 这 样 操作 ， 就 可 
以 完成 向 空 的 裸 版 本 库 的 推送 。 


$git push/path/to/repos/demo-init.git master:master 
Counting objects:26, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(20/20), done. 

Writing objects:100%(26/26),2.49 KiB, done. 

Total 26(delta 8),reused 0O(delta 0) 

Unpacking objects:100%(26/26), done. 
To/path/to/repos/demo-init.git 

*[new branch]master-~>master 


上 面 的 git push 命 令 也 可 以 简写 为 :git push/path/to/repos/demo- 


init.git master ° 


推送 成 功 了 吗 ? 看 看 demo-init.git 版 本 库 中 的 提交 。 


$git--git-dir=/path/to/repos/demo-init.git log--oneline-2 
©0285742 Sync test 4 
d4b42b7 sync test 3 


好 了 继续 在 demo 中 执行 几 次 提交 。 


$cd/path/to/my/workspace/demo/ 

$git commit--allow-empty-m "sync test 5" 
[master 424aa67]sync test 5 

$git commit--allow-empty-m "sync test 6" 


[master 70a5aa7]Ssync test 6 


然后 再 癌 demo-init.git 推 送 。 注 意 这 次 使 用 的 命令 。 


$git push/path/to/repos/demo-init.git 
Counting objects:2, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 
Writing objects:100%(2/2),273 bytes, done. 
Total 2(delta 1),reused 0O(delta 0) 
Unpacking objects:100%(2/2),done. 
To/path/to/repos/demo-init.git 
0285742..70a5aa7 master-~>master 


为 什么 这 次 使 用 git push 命 令 后 面 没有 跟 上 分 文 名 呢 ? 这 是 因为 远 
程 版 本 库 (demo-init.git) 中 已 经 不 再 是 空 版 本 库 了 ， 有 名 为 master 的 
他 这 


通过 下 面 的 命令 可 以 查看 远程 版 本 库 的 分 文 。 


$git ls-remote/path/to/repos/demo-init.git 
70a5aa7a7469076fd435a9e4f89c4657ba603ced HEAD 
70a5aa7a7469076fd435a9e4f89c4657ba603ced refs/heads/master 


至 此 相信 您 已 经 能 够 把 鸡蛋 放 在 不 同 的 篮子 中 了 ， 也 对 使 用 Git 更 
加 有 信心 了 吧 。 


第 14 章 ”Git 库 管理 
版 本 库 管理 ? 那 不 是 管理 员 要 干 的 事情 么 ， 怎 么 放 在 <Git 独 奏 " 这 
一 部 分 了 ? 


没有 错 ， 这 是 因为 对 于 Git， 每 个 用 户 都 是 目 己 版 本 库 的 管理 员 ， 
所 以 在 “Git 独 奏 ” 的 最 后 一 章 ， 我 们 来 谈 一 谈 Git 版 本 库 管理 的 问题 。 如 
果 下 面 的 问题 您 没有 直到 或 不 感 兴 趣 ， 大 可 以 放心 地 跳 过 这 一 章 。 


从 网 上 克隆 来 的 版 本 库 ， 为 什么 对 和 象 库 中 找 不 到 对 象 文 件 ? 而 且 
引用 目录 里 也 看 不 到 所 有 的 引用 文件 ? 


不 小 心 添加 了 一 个 大 文件 到 Git 库 中 ， 用 重 置 命令 丢弃 了 包含 大 文 
件 的 提交 ， 可 是 版 本 库 不 见 小 ， 大 文件 仍 在 对 象 库 中 。 


本 地 版 本 库 的 对 象 库 里 的 文件 越 来 越 多 ， 这 可 能 导致 Git 性 能 的 降 
候 


14.1 对 象 和 引用 哪里 去 了 


从 Github 上 克隆 一 个 示例 版 本 库 ， 这 个 版 本 库 在 “第 11 划 历史 罕 
梭 ” 一 草 束 已 经 克隆 过 一 次 了 ， 现 在 要 重新 克隆 一 份 。 为 了 和 原来 的 元 
笨 相 区 别 ， 我 们 将 克隆 到 男 外 的 目录 。 执 行 下 面 的 命令 。 


$cd/path/to/my/workspace/ 

$git clone git://github.com/ossxp-com/gitdemo-commit-tree.git i- 
am-admin 

Cloning into i-am-admin... 

remote:Counting objects:65,done. 

remote:Compressing objects:100%(53/53),done. 

remote:Total 65(delta 8),reused 0(delta 0) 

Receiving objects:100%(65/65),78.14 KiB|42 KiB/s, done. 

Resolving deltas:100%(8/8),done. 


进入 克隆 的 版 本 库 ， 使 用 git show-ref 命 令 看 看 所 包含 的 引用 。 


$cd/path/to/my/workspace/i-am-admin 
$git show-ref 
6652a0dce6a5067732c0gef0a220810a7230655e refs/heads/master 
6652a0dce6a5067732c00efg0a220810a7230655e 
refs/remotes/origin/HEAD 
6652a0dce6a5067732c00ef0a220810a7230655e 
refs/remotes/origin/master 
c9b03a208288aebdbfe8d84aeb984952a16da3f2 refs/tags/A 
1a87782f8853c6e11aacba463af04b4fa8565713 refs/tags/B 
9f8b51bc7dd98f7501ade526dd78c55ee4abb75f refs/tags/CcC 
887113dc095238a0f4661400d33ea570e5edc37c refs/tags/D 
6decdoad3201ddb3f5b37c201387511059ac120c refs/tags/E 
70cab20f099egoaf3f870956a3fbbbda50a17864f refs/tags/F 
96793e37c7f1ic7b2ddf69b4c1ie252763c11a711f refs/tags/6 
476e74549047e2c5fbd616287a499cc6fo7ebde0 refs/tags/H 
76945a15543c49735634d58169b349301d65524d refs/tags/I 
f199c10c3f1a54fa3f9542902b25b49d58efb35b refs/tags/]J 


其 中 以 refs/heads/ 开 头 的 是 分 文 ; 以 refs/remotes/ 开 头 的 是 远程 版 
本 库 分 支 在 本 地 的 映射 ， 这 会 在 后 面 的 章节 中 介绍 ; 以 refs/tags/ 开 头 
的 是 里 程 碑 。 按 照 之 前 的 经 验 ， 在 .gityrefs 目 录 下 应 该 有 这 些 引 用 所 对 
应 的 文件 才 是 。 看 看 都 在 么 ? 


$find.git/refs/-type f 
.git/refs/remotes/origin/HEAD 


.git/refs/heads/master 


为 什么 才 有 两 个 文件 ? 实际 上 当 运 行 下 面 的 命令 后 ，3 引 用 目录 下 
的 文件 会 更 少 : 
$git pack-refs--all 


$find.git/refs/-type f 
.git/refs/remotes/origin/HEAD 


那么 本 应 该 出 现在 .gitrefs/ 目 孙 下 的 引用 文件 都 到 哪里 去 了 呢 ? 管 
案 是 这 些 文件 被 打包 了 ， 放 到 一 个 文本 文件 .git/packed-refs 中 了 。 查 看 
一 下 这 个 文件 中 的 内 容 。 


$head-5.git/packed-refs 

#pack-refs with:peeled 

6652a0dce6a5067732c0gef0a220810a7230655e refs/heads/master 

6652a0dce6a5067732c00efg0a220810a7230655e 
refs/remotes/origin/master 

c9b03a208288aebdbfe8d84aeb984952a16da3f2 refs/tags/A 

和 81993234fc12a325d303eccea20f6fd629412712 


再 来 看 看 Git 的 对 象 (commit、blob、tree、tag) 在 对 象 库 中 的 存 
储 。 通 过 下 面 的 命令 ， 会 发 现 对 象 库 也 不 是 原来 熟悉 的 模样 了 。 


$find.git/objects/-type f 

.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.idx 

.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.pack 


对 象 库 中 只 有 两 个 文件 ， 本 应 该 一 个 一 个 独立 保存 的 对 象 都 不 见 
了 。 您 应 该 能 够 猜 到 ， 所 有 的 对 象 文件 都 被 打包 到 这 两 个 文件 中 了 ， 
其 中 以 ,pack 结尾 的 文件 是 打包 文件 ， 以 .idx 结 尾 的 是 索引 文件 。 打 包 
文件 和 对 应 的 索引 文件 只 是 扩展 名 不 同 ， 都 保存 于 .gitobjects/pack/ 目 
杂 下 。Git 对 于 以 SHA1 哈 硕 值 作为 目录 名 和 文件 名 保存 的 对 象 有 一 个 
术语 ， 称 为 松散 对 象 。 松 散 对 象 打包 后 会 提高 访问 效率 ， 而 且 不 同 的 
对 象 可 以 通过 增 量 存储 节省 磁盘 空间 。 


通过 Git 一 个 底层 的 命令 可 以 碍 看 索引 中 包含 的 对 象 : 


$git show-index< .git/objects/pack/pack-*.idx|head-5 

661 Qcd7f2ea245d90d414e502467ac749f36aa32cc4(0793420b) 
63020 1026d9416d6fc8d34eledfb2bc58adb8aa5a6763(ed77ff72) 
3936 15328fc6961390b4b10895f39bb042021edd07ea(13fb79ef) 
3768 1a588ca36e25f58fbeae421c36d2c39e38e991ef(86e3b0bd) 
2022 1a87782f8853c6e11aacba463af04b4fa8565713(e269ed74) 


为 什么 克隆 远程 版 本 库 就 可 以 产生 对 象 库 打 包 及 引用 打包 的 效果 
呢 ? 这 是 因为 元 隆 远 程 版 本 库 时 ， 使 用 了 “智能 ”的 通信 协议 ， 远 程 Git 
服务 器 将 对 象 打包 后 传输 给 本 地 ， 形 成 本 地 版 本 库 的 对 象 库 中 的 一 个 
包含 所 有 对 和 象 的 包 及 索引 文件 。 无 疑 这 样 的 传输 方式 一 一 按 需 传输 、 
打包 传输 一 一 效率 最 高 。 


克隆 之 后 的 版 本 库 在 日 营 的 提交 中 ,产生 的 新 对 象 仍旧 以 松散 对 
象 人 存在， 而 不 是 以 打包 的 形式 ， 日 积 月 素 会 在 本 地 版 本 库 的 对 象 库 中 
形成 大 量 的 松散 文件 。 松 散 对 象 只 是 进行 了 压缩 ， 而 没有 (打包 文件 


才 有 的 ) 增 量 存 储 的 功能 ， 会 浪费 磁盘 空间 ， 也 会 降低 访问 效率 。 更 
为 严重 的 是 一 些 非 正式 的 临时 对 象 (和 暂 存 区 操作 中 产生 的 临时 对 和 象 ) 
也 以 松散 对 象 的 形式 保存 在 对 象 库 中 ， 造 成 磁 副 空间 的 浪 线 。 下 一 市 
忠 厦 手 处 理 临 时 对 和 象 的 问题 。 


14.2 ”和 暂 存 区 操作 引入 的 临时 对 象 


暂 存 区 操作 有 可 能 在 对 象 库 中 产生 临时 对 象 ， 例 如 ， 文 件 反 复 地 
修改 、 反 复 地 向 暂 存 区 添加 ， 或 者 添加 到 和 暂 存 区 后 不 提交 甚至 直接 撤 
销 ， 就 会 产生 垃圾 数据 占用 磁盘 空间 。 为 了 说 明 临 时 对 象 的 问题 ， 需 
要 准备 一 个 大 的 压缩 文件 ，10MB 即 可 。 


在 Linux 上 与 内 核 匹 配 的 initrd 文 件 《内 核 局 动 加 载 的 内 存 副 ) 就 
是 一 个 大 的 压缩 文件 ， 可 以 用 于 此 节 的 示例 。 将 大 的 压缩 文件 放 在 版 
本 库 外 的 一 个 目 永 上 ， 因 为 这 个 文件 会 多 次 用 到 * 


$cp/boot/initrd.img-2.6.32-5-amd64/tmp/bigfile 
$du-sh/tmp/bigfile 
11M/tmp/bigfile 


将 这 个 大 的 压缩 文件 复制 到 工作 区 中 ， 复 制 两 份 。 


$cd/path/to/my/workspace/i-am-admin 
$cp/tmp/bigfile bigfile 
$cp/tmp/bigfile bigfile.dup 


然后 将 工作 区 中 两 个 内 容 完全 一 样 的 大 文件 加 入 暂 存 区 。 


$git add bigfile bigfile.dup 


查看 一 下 磁 组 空间 占用 : 


工作 区 连同 版 本 库 共 占用 33MB 。 


$du-sh. 
33M. 


其 中 版 本 库 只 占用 了 11MB。 版 本 库 空间 占用 是 工作 区 的 一 半 。 


如 采 再 有 谁 说 版 本 库 空 间 占 用 一 定 比 工作 区 大 ， 可 以 用 这 个 例子 
回击 他 。 


$du-sh.git/ 
11M.git/ 


看 看 版 本 库 中 对 象 库 内 的 文件 ， 会 发 现 多 出 了 一 个 松散 对 象 。 之 
所 以 添加 两 个 文件 而 只 有 一 个 松散 对 象 ， 是 因为 Git 对 于 文件 的 保存 是 
将 内 容 保存 为 blob 对 象 中 ， 和 文件 名 无 关 ， 相 同 内 容 的 不 同文 件 会 共 
享 同 一 个 blob 对 象 。 


$find.git/objects/-type f 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.idx 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.pack 


如 采 不 想 提 交 ， 想 将 文件 撤 出 暂 存 区 ， 则 进行 如 下 操作 。 


(1) 查看 当前 暂 存 区 的 状态 。 


$git status-s 
A bigfile 
A bigfile.dup 


(2) 将 添加 的 文件 撤 出 暂 存 区 。 


$git reset HEAD 


(3) 通过 查看 状态 ， 看 到 文件 被 撤 出 暂 存 区 了 。 


$git status-s 
?2? bigfile 
?2? bigfile.dup 


文件 撤 出 暂 存 区 后 ， 在 对 象 库 中 产生 的 blob 松 散 对 象 仍然 存在 ， 
通过 查看 版 本 库 的 磁盘 占用 束 可 以 看 出 来 。 
$du-sh.git/ 
11M.git/ 
Git 提 供 了 git fsck 命 令 ， 可 以 查看 到 版 本 库 中 包含 的 没有 被 任何 引 
用 关联 的 松散 对 象 。 


$git fsck 
dangling blob 2ebcd92dodda2bad50c775dc662c6cb700477aff 


标识 为 dangling 的 对 象 束 是 没有 被 任何 引用 直接 或 间接 关联 a 到 的 对 
象 。 这 个 对 象 殉 是 前 面 通过 暂 存 区 操作 引入 的 大 文件 的 内 容 。 如 何 将 
这 个 文件 从 版 本 库 中 彻底 删除 呢 ? Git 提 供 了 一 个 清理 的 命令 : 


$git prune 


用 git prune 清 理 之 后 ， 会 发 现 : 


用 git fsck 查 看 ， 没 有 未 被 天 联 到 的 松散 对 象 。 


$git fsck 


版 本 库 的 空间 占用 也 小 了 10MB， 证 明 大 的 临时 对 象 文件 已 经 从 
版 本 库 中 删除 了 。 


$du-sh.git/ 
236K.git/ 


14.3 重 置 操作 3 引入 的 对 象 


上 一 市 用 git prune 命 令 清除 和 暂 存 区 操作 时 引入 的 临时 对 象 ， 但 是 
如 果 是 用 重 置 命令 抛弃 的 提交 和 文件 束 不 会 轻易 地 被 清除 。 下 面 用 同 
样 的 大 文件 提交 到 版 本 库 中 试验 一 下 。 


$cd/path/to/my/workspace/i-am-admin 
$cp/tmp/bigfile bigfile 
$cp/tmp/bigfile bigfile.dup 


将 这 两 个 大 文件 提交 到 版 本 库 中 。 


添加 到 暂 存 区 。 


$git add bigfile bigfile.dup 


是 区 到 版 本 库 。 


$git commit-m "add bigfiles," 

[master 51519c7]add bigfiles. 

2 files changed,0 insertions(+),0 deletions(-) 
create mode 100644 bigfile 

create mode 100644 bigfile.dup 


查看 版 本 库 的 空间 占用 。 


$du-sh.git/ 
11M.git/ 


做 一 个 重 置 操 作 ， 抛 弃 刚 刚 针 对 两 个 大 文件 做 的 提交 。 


$git reset--hard HEADA^ 


重 置 之 后 ， 看 看 版 本 库 的 变化 。 


版 本 库 的 空间 占用 没有 变化 ， 还 是 那么 庞大 ”。 


$du-sh.git/ 
11M.git/ 


查看 对 象 库 ， 看 到 三 个 松散 对 象 。 


$find.git/objects/-type f 
.git/objects/info/packs 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 
.git/objects/d9/38dee8fde4e5053b12406c66a19183a24238e1 
.git/objects/51/519c7d8d60e0f958e135e8b989a78e84122591 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.idx 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.pack 


这 三 个 松散 对 象 分 别 对 应 于 撤销 的 提交 、 目 录 树 ， 以 及 大 文件 对 
应 的 blob 对 象 。 


$git cat-file-t 51519c7 
commit 

$git cat-file-t d938dee 
tree 

$git cat-file-t 2ebcd92 
blob 


器 上 一 节 一 样 ， 执 行 git prune 命 令 ， 期 待 版 本 库 空间 占用 会 变 
小 。 可 是 : 


版 本 库 空 间 占 用 没有 变化 ! 


$git prune 
$du-sh.git/ 
11M. git/ 


执行 git fsck 也 看 不 到 未 被 关联 a 到 的 对 象 。 
$git fsck 
除非 像 下 面 这 样 执行 。 


$git fsck--no-reflogs 
dangling commit S51519c7d8d60e0f958e135e8b989a78e84122591 


还 记得 前 面 章 节 中 介绍 的 reflog 吗 ? reflog 是 防止 误 操 作 的 最 后 一 
道 闸 门 。 
$git reflog 


6652a0d HEAD@{0}:HEAD^:updating HEAD 
51519c7 HEAD@{1}:commit:add bigfiles. 


可 以 看 到 撤销 的 操作 仍然 记录 在 reflog 中 ， 正 因为 如 此 ，Git 认 为 
撤销 的 提交 和 大 文件 都 可 以 被 追踪 到 ， 还 在 使 用 着 ， 所 以 无 法 用 git 


prune 命 令 删除 。 


如 果 确 认真 的 要 丢弃 不 想 要 的 对 象 ， 需 要 对 版 本 库 的 reflog 做 过 期 
操作 ， 相 当 于 将 .givlogs/ 下 的 文件 清空 。 


使 用 下 面 的 reflog 过 期 命令 做 不 到 让 刚刚 撤销 的 提交 过 期 ， 因 为 
reflog 的 过 期 操作 默认 只 会 让 90 天 前 的 数据 过 期 。 

$git reflog expire--all 

$git reflog 


6652a0d HEAD@{0}:HEAD^:updating HEAD 
51519c7 HEAD@{1}:commit:add bigfiles. 


需要 为 git reflog 命 令 提 供 --expire= < date> 参数 ， 强 制 让 < date> 
之 前 的 记录 全 部 过 期 。 


$git reflog expire--expire=now--all 
$git reflog 


使 用 now 作 为 时 间 参 数 ， 计 reflog 的 全 部 记录 都 过 期 。 没 有 了 
reflog， 即 从 reflog 中 看 不 到 回 深 的 添加 大 文件 的 提交 后 ， 该 提交 对 应 
的 commit 对 象 、tree 对 象 和 blob 对 象 就 会 成 为 末 被 天 联 的 dangling 对 
象 ， 可 以 用 git prune 命 令 清理 。 下 面 可 以 看 到 清理 后 ， 版 本 库 变 小 
各 

$git prune 


$du-sh.git/ 
244K .git/ 


14.4” Git 管家: git-gc 


前 面 两 广 介 绍 的 是 比较 极端 的 情况 ， 实 际 操作 中 会 很 少 用 到 git 
prune 命 令 来 清理 版 本 库 ， 而 是 会 使 用 一 个 更 为 常用 的 命令 git gc。 命 令 
git gc 歼 好 比 Git 版 本 库 的 管家 ， 会 对 版 本 库 进 行 一 系列 的 优化 动作 : 


(1) 对 分 散在 .gitrefs 下 的 文件 进行 打包 ， 打 包 到 文件 .git/packed- 
refs 中 。 


如 果 没 有 将 配置 gc.packrefs 关 闭 ， 束 会 执行 命令 :git pack-refs-- 
all--prune 实 现 对 引用 的 打包 。 


(2) 丢弃 90 天 前 的 reflog 记 录 。 


会 运行 reflog 过 期 命令 : git reflog expire--all。 因 为 采用 了 默认 参数 
调用 ， 因 此 只 会 清空 reflog 中 90 天 前 的 记录 。 


(3) 对 松散 对 象 进行 打包 。 


运行 git repack 命 令 ， 凡 是 有 引用 关联 的 对 象 都 被 打 在 包 里 ， 未 被 
关联 的 对 象 仍旧 以 松散 对 象 的 形式 保存 。 


(4) 清除 未 被 关联 的 对 象 。 默 认 只 清除 2 周 以 前 的 未 被 关联 的 对 


可 以 同 git gc 提供 --prune=<date> 参数 ， 其 中 的 时 间 参 数 传递 给 git 
prune--expire < date > ， 实 现 对 指定 日 期 之 前 的 未 被 关联 的 松散 对 象 进 
行 清理 。 


(5) 其 他 清理 。 
如 运行 git rerere gc 对 合并 冲突 的 历史 记录 进行 过 期 操作 。 


从 上 面 的 描述 中 可 见 命令 git gc 完成 了 相当 多 的 优化 和 清理 工作 ， 
并 且 最 大 限度 地 照顾 了 安全 性 的 需要 。 例 如 像 暂 存 区 操作 引入 的 没有 
关联 的 临时 对 和 象 会 最 少 保留 2 个 星期 ， 而 因为 重 置 而 丢弃 的 提交 和 文件 


则 会 保留 最 少 3 个 月 。 


下 面 束 把 前 面 的 例子 用 git gc 再 执行 一 过， 不 过 这 一 次 添加 的 两 个 
大 文件 要 稍 有 不 同 ， 以 便 看 到 git gc 打包 所 实现 的 对 象 增 量 存储 的 效 
果 。 


复制 两 个 大 文件 到 工作 区 。 


$cp/tmp/bigfile bigfile 
$cp/tmp/bigfile bigfile.dup 


在 文件 bigfile.dup 后 面 妃 加 些 内 容 ， 以 造成 bigfile 和 bigfile.dup 内 容 
不 同 。 


$echo "hello world">~>bigfile.dup 


N| 


将 这 两 个 稍 有 不 同 的 文件 提交 到 版 本 库 。 


$git add bigfile bigfile.dup 

$git commit-m "add bigfiles." 

[master c62fa4dl]add bigfiles. 

2 files changed,0 insertions(+),0 deletions(-) 
create mode 100644 bigfile 

create mode 100644 bigfile.dup 


可 以 看 到 版 本 库 中 提交 进来 的 两 个 不 同 的 大 文件 是 不 同 的 对 象 。 


$git ls-tree HEAD|grep bigfile 
100644 blob 2ebcd92dodda2bad50c775dc662c6cb700477aff bigfile 
100644 blob 9e35f946a30c11c47baldf351ca22866bc351e7b bigfile.dup 


做 版 本 库 重 置 ， 抛 弃 最 新 的 提交 ， 即 抛弃 添加 两 个 大 文件 的 提 


$git reset--hard HEADA^ 
HEAD is now at 6652a0d Add Images for git treeview. 


此 时 的 版 本 库 有 多 大 呢 ， 还 古 像 之 前 添加 两 个 相同 的 大 文件 时 占 


用 11MB 的 空间 么 ? 


$du-sh.git/ 
22M.git/ 


版 本 库 空间 占用 居然 扩大 了 一 信 ! 这 显然 是 因为 两 个 大 文件 分 开 


存储 造成 的 。 可 以 用 下 面 的 命令 在 对 象 库 中 查看 对 象 的 大 小 。 


$find.git/objects-type f-printf "%-20p\t%s\n" 
.git/objects/0c/844d2a072fd69e71638558216b69ebc57ddb64 233 
.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 11184682 
.git/objects/9e/35f946a30c11ic47baidf351ca22866bc351e7b 11184694 
.git/objects/c6/2fa4d6cb4c082fadfa45920b5149a23fd7272e 162 
.git/objects/info/packs 54 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.idx 2892 
.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.pack 80015 


输出 的 每 一 行 用 空白 分 隔 ， 前 面 征文 件 名 ， 后 面 是 以 字 节 为 单位 
的 文件 大 小 。 从 上 面 的 输出 中 可 以 看 出 来 ， 打 包 文 件 很 小 ， 但 是 有 两 
个 大 的 文件 各 自 占用 了 11MB 左 右 的 空间 。 


执行 git gc 并 不 会 删除 任何 对 象 ， 因 为 这 些 对 象 都 还 没有 过 期 。 但 
征 会 发 现 版 本 库 的 占用 空间 要 小 了 。 


执行 git gc 对 版 本 库 进 行 整理 。 


$git gc 

Counting objects:69, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(49/49),done. 
Writing objects:100%(69/69),done. 

Total 69(delta 11),reused 63(delta 8) 


版 本 库 空 间 占 用 小 了 一 半 ! 


$du-sh.git/ 
11M.git/ 


原来 是 因为 对 象 库 重 新 打包 ， 两 个 大 文件 采用 了 增 量 存储 使 得 版 
本 库 变 小 
$find.git/objects-type f-printf "%-20p\t%s\n"|sort 
.git/objects/info/packs 54 
.git/objects/pack/pack- 
7cae010c1b064406cd6c16d5a6ab2f446de4076c.idx 3004 


.git/objects/pack/pack- 
7cae010c1b064406cd6c16d5a6ab2f446de4076c .pack 11263033 


如 有 果 想 将 抛弃 的 历史 数据 彻 捷 丢弃， 进行 如 下 操作 。 
(1) 不 再 保留 90 天 的 reflog， 而 是 将 所 有 reflog 全 部 即时 过 期 。 


$git reflog expire--expire=now--all 


(2) 通过 git fsck 可 以 看 到 有 提交 成 为 了 未 被 关联 的 提交 。 


$git fsck 
dangling commit c62fa4d6cb4c082fadfa45920b5149a23fd7272e 


(3) 这 个 未 被 关联 的 提交 就 是 添加 大 文件 的 提交 。 


$git Show c62fa4d6cb4c082fadfa45920b5149a23fd7272e 
commit c62fa4d6cb4c082fadfa45920b5149a23fd7272e 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Dec 16 20:18:38 2010+0800 

add bigfiles. 

diff--git a/bigfile b/bigfile 

new file mode 100644 

index 0000000, .2ebcd92 

Binary files/dev/null and b/bigfile differ 
diff--git a/bigfile.dup b/bigfile.dup 

new file mode 100644 


index 0000000. .9e35f94 
Binary files/dev/null and b/bigfile.dup differ 


(4) 不 带 参 数 调用 git gc 虽然 不 会 清除 尚未 过 期 (未 到 2 周 ) 的 大 
文件 ， 但 是 会 将 未 被 关联 的 对 象 从 打包 文件 中 移出 ， 成 为 松散 文件 。 


$git gc 

Counting objects:65, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(45/45),done. 
Writing objects:100%(65/65),done. 

Total 65(delta 8),reused 63(delta 8) 


(5) 未 被 关联 的 对 象 重新 成 为 松散 文件 ， 所 以 .git 版 本 库 的 空间 
占用 又 反弹 了 。 


$du-sh.git/ 

22M.git/ 

$find.git/objects-type f-printf "%-20p\t%s\n"|sort 

.git/objects/0c/844d2a072fd69e71638558216b69ebc57ddb64 233 

.git/objects/2e/bcd92dodda2bad50c775dc662c6cb700477aff 11184682 

.git/objects/9e/35f946a30c11ic47baidf351ca22866bc351e7b 11184694 

.git/objects/c6/2fa4d6cb4c082fadfa45920b5149a23fd7272e 162 

.git/objects/info/packs 54 

.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.idx 2892 

.git/objects/pack/pack- 
969329578b95057b7ea1208379a22c250c3b992a.pack 80015 


(6) 实际 上 如 果 使 用 立即 过 期 参数 --prune=now 调 用 git gc， 束 不 
用 再 等 2 周 了， 直接 束 可 以 完成 对 未 关联 的 对 象 的 清理 。 


$git gc--prune=now 
Counting objects:65,done. 
Delta compression using up to 2 threads. 


Compressing objects:100%(45/45),done. 
Writing objects:100%(65/65),done. 
Total 65(delta 8),reused 65(delta 8) 


(7) 清理 过 后 ， 版 本 库 的 空间 占用 降 了 下 来 。 


$du-sh.git/ 
240K.git/ 


14.5 _ Git 管 家 的 目 动 执 行 


对 于 老 版 本 库 的 Git， 会 看 到 帮助 手册 中 建议 用 户 对 版 本 库 进 行 周 
期 性 的 整理 ， 以 便 获 得 更 好 的 性 能 ， 尤 其 是 对 于 规模 比较 大 的 项 目 ， 
但 是 对 于 整理 的 周期 都 语 融 不 详 。 


实际 上 对 于 1.6.6 及 以 后 版 本 的 Git 已 经 基本 上 不 需要 手动 执行 git gc 
命令 了 ， 因 为 部 分 Git 命 令 会 自动 调用 git gc--auto 命 令 ， 在 版 本 库 确 实 
需要 整理 的 情况 下 自动 开始 整理 操作 。 

目前 有 如 下 的 Git 命 令 会 自动 执行 git gc--auto 命 令 ， 实 现 对 版 本 库 
的 按 需 整理 。 

执行 命令 git merge 进 行 合 并 操作 后 ， 对 版 本 库 进 行 按 需 整理 。 

执行 命令 git receive-pack， 即 版 本 库 接 收 其 他 版 本 库 PUSH 来 的 提 
区 后 ， 对 版 本 库 进 行 按 需 整理 操作 。 


当 版 本 库 接 收 到 其 他 版 本 库 的 PUSH 请 求 时 ， 会 调用 git receive- 
pack 命 令 以 接收 请 求 。 在 接收 到 推送 的 提交 后 ， 对 版 本 库 进行 按 需 整 
理 。 


执行 命令 git rebase-i 进 行 交 互 式 变 基 操 作 后 ， 会 对 版 本 库 进 行 按 需 
整理 。 


执行 命令 git am 对 mbox 邮 箱 中 通过 邮件 提交 的 补丁 在 版 本 库 中 进 
行 应 用 的 操作 后 ， 会 对 版 本 库 做 按 需 整理 操作 。 


综 上 所 述 ， 对 于 提供 共 主 式 “ 写 操作 ”的 Git 碑 本 库 ， 可 以 免 维护 。 
所 谓 的 共 皇 式 写 操作 ， 束 旦 版 本 库 作为 一 个 裸 厂 本 库 放 在 服务 郁 上 ，， 
团队 成 员 可 以 通过 PUSH (推送 ) 操作 将 提交 推送 到 共 译 的 裸 版 本 
中 。 每 一 次 推送 操作 都 会 触发 git gc--auto 命 令 ， 对 版 本 库 进行 按 需 整 
理 。 


还 有 ， 对 于 非 独 立 工作 的 本 地 工作 区 ， 也 可 以 免 维护 。 因 为 和 他 
人 协同 工作 的 本 地 工作 区 会 经 党 执行 git pull 操 作 从 他 人 版 本 库 或 从 共 
享 的 版 本 库 拉 回 新 提交 ， 执 行 git pull 操 作 会 触发 git merge 操 作 ， 因 此 
也 会 对 本 地 版 本 库 进 行 按 需 整理 。 


在 对 版 本 库 进 行 按 需 整 理 时 ， 整 理 的 频率 是 一 个 问题 。 如 有 果 整 理 
得 太 勤 则 没有 必要 ， 还 会 增加 系统 负担 ; 但 如 果 蚊 于 整理 则 会 导致 积 
累 太 多 的 松散 文件 ， 当 真正 开始 版 本 库 整 理 的 时 候 会 占用 过 多 的 系统 
资源 ， 影 响 用 户 体验 。 因 此 实际 操作 中 只 有 在 特定 的 条 件 下 才 会 触发 
真正 的 版 本 库 整 理 。 


主要 的 触发 条 件 是 : 松散 对 象 只 有 超过 一 定 的 数量 时 才 会 执行 。 
在 统计 松散 对 象 数 量 时 ， 为 了 降低 在 .git/objects/ 目 录 下 搜索 松散 对 象 
对 系统 造成 的 负担 ， 实 际 采取 了 取样 搜索 ， 即 只 会 对 对 象 库 下 的 一 个 
子 日 录 .git/objects/17 进 行文 件 搜索 。 在 默认 的 配置 下 ， 只 有 该 日 录 中 
对 象 数目 超过 27 个 才 会 触发 版 本 库 的 整理 。 至 于 为 什么 只 在 对 象 库 中 
选择 一 个 子 目录 进行 松散 对 象 的 搜索 ， 这 是 因为 SHA1 哈 希 值 是 完全 随 
机 的 ， 文 件 在 由 前 两 位 哈 希 值 组 成 的 目录 中 差不多 是 平均 分 布 的 。 至 
于 为 什么 选择 17， 不 知道 对 于 作者 Junio C Hamano 有 什么 特殊 意义 ， 
也 许 是 向 Linus Torvalds 被 评选 为 20 世 纪 最 有 影响 力 的 100 人 中 排名 第 17 
位 而 致敬 [1 。 


可 以 通过 设置 配置 变量 gc.auto 的 值 ， 调 整 Git 管 家 自动 运行 时 触发 
版 本 库 整 理 操作 的 频率 。 默 认 gc.auto 的 值 为 6700， 是 触发 版 本 库 整 理 
的 全 部 松散 对 象 数 的 病 值 ， 对 于 单个 取样 目录 .git/objects/17 来 说 ， 超 
过 “(6700+255) /256 个 文件 时 即 开始 版 本 库 整 理 。 但 是 注意 不 要 将 
gc.auto 设 置 为 0， 否 则 git gc--auto 命 令 永远 不 会 触发 版 本 库 的 整理 。 


[1| http://en.wikipedia.org/wiki/Linus_Torvalds 


第 3 篇 ”Git 和 声 


上 一 篇 的 各 章 是 从 个 人 使 用 的 角度 研究 和 学 习 Git， 通 过 连续 的 实 
践 不 但 学 习 了 Git 的 基本 用 法 ， 还 深入 地 了 解 了 Git 的 奥秘 ， 这 些 都 将 
成 为 学 习 本 篇 内 容 的 基础 。 本 篇 不 再 是 一 个 人 的 独奏 ， 而 是 多 人 的 和 
声 ， 我 们 将 从 团队 使 用 的 角度 对 Git 进 行 研究 。 要 知道 Git 作 为 版 本 控 
制 系统 ， 其 主要 工作 就 是 团队 协作 。 


团队 协作 和 个 人 之 间 有 何不 同 ? 关键 束 在 于 团队 成 员 之 间 存 在 着 
数据 交换 : 


数据 交换 需要 协议 ， 这 束 古 第 15 章 要 介绍 的 内 容 。 


数据 交换 可 能 会 因为 冲突 造成 中 断 ， 第 16 章 将 专题 介绍 如 何 解决 


冲突 。 


里 程 碑 为 数据 建立 标识 ， 是 数据 交换 的 参照 后 ， 这 将 在 第 17 章 中 


I 


分 支 会 为 数据 交换 开辟 不 同 的 通道 ， 从 而 减少 冲突 和 混乱 的 发 
生 ， 第 18 章 会 系统 地 介绍 不 同 的 分 支 应 用 模型 。 


与 远程 版 本 库 进 行 数据 交换 ， 是 Git 协 同 的 重要 内 容 ， 这 将 在 第 19 


章 中 介绍 。 


本 篇 的 最 后 (第 20 章 ) 会 介绍 在 不 能 直接 与 其 他 版 本 库 交互 的 情 
况 下 ， 如 何以 补丁 文件 的 方式 进行 数据 交换 。 


第 15 划 ”Git 协议 与 工作 协同 
要 想 团队 协作 使 用 Git， 就 需要 用 到 Git 协 议 。 
15.1 Git 支持 的 协议 


首先 来 看 看 数据 交换 需要 使 用 的 协议 。 


Git 提 供 了 丰富 的 协议 支持 ， 包 括 : SSH、GIT、HTTP、HTTPS、 
FIP、FTPS、RSYNC 及 前 面 已 经 看 到 的 本 地 协议 等 。 各 种 不 同 协 议 的 
URL 写 法 如 表 15-1 所 示 。 


表 15-1 Git 支持 的 协议 


协 议 名 称 语法 格式 说 天 

SSH 协议 (1) ssh:i/[usen@ jexample.comf{:portjipathitoirepo.git/ | 可 在 URL 中 设置 用 户 名 和 问 妃 。 上 默认 端口 22 
SCP 格式 表示 法 ， 更 简洁 。 但 是 非 默 认 疹 

SSH 协议 (2) [usen@ example.com:path/to/rcpo.2it 口 需 要 通过 其 他 方式 “如 主机 别名 方式 ) 
设 定 

GIT 协议 git://cxample.com{:port) pathito/repo.git 最 常用 的 只 读 协 议 

HTTP[S] 协议 http[s]:/example.coml:port]/path/to/rcpo.git 兼 有 智能 协议 和 哑 协 议 

FTP[S] 协议 fip[sj:Jexample.comf:port]/ipathito/repo.git, 于 协议 

RSYNC 协议 rsync-Jexample.com/path/to/repo.wit 绪 协 议 


本 地 协议 (1) file:///path/to/repo.git 
和 file:i/ 格式 的 本 地 协议 类 似 ， 但 有 细微 凌 
林地 掉 议 《2) jpathyjtoyrcpo-git 别 。 例 如 克隆 时 不 支持 茂 克隆 ， 且 采用 直接 
的 看 连接 实现 克 降 


上 面 介绍 的 各 种 协议 可 分 为 两 尖 : 智能 协议 和 哑 协 议 。 
1. 智 能 协议 


企 会 话 时 使 用 智能 协议 ， 会 在 会 话 的 两 个 版 本 库 的 各 自 一 端 打 开 
相应 的 程序 进行 数据 交换 。 使 用 智能 协议 最 直观 的 印象 就 是 在 数据 传 
输 过 程 中 会 有 清晰 的 进度 显示 ， 而 且 因为 是 按 需 传输 所 以 传输 量 更 
小 ， 速 度 更 快 。 图 15-1 显 示 的 就 是 在 执行 PULL 和 PUSH 两 个 最 常用 的 
操作 时 ， 两 个 版 本 库 各 上 自 启 动 辅 助 程序 的 情况 。 


git push 
git-send-pack git-receive-pack 


git-fetch-pack git-upload-pack 


本 地 版 本 库 远程 版 本 库 


15-1  Git 智 能 协议 通信 示意 图 


上 述 协 议 中 SSH、GIT 及 本 地 协议 \file:/) 属于 智能 协议 。HTTP 
协议 需要 特殊 的 配置 (用 git-http-backend 配 置 CGI) ， 并 且 客 户 端 需要 
使 用 Git 1.6.6 或 更 高 的 版 本 才能 够 使 用 智能 协议 。 


2. 呈 协议 


和 智能 协议 相对 的 有 古 吧 协议 。 在 使 用 呈 协 议 访问 远程 版 本 库 的 时 
候 ， 远 程 版 本 库 不 会 运行 辅助 程序 ， 而 是 完全 依靠 客户 端 去 主动 "发 
现 ”。 客 户 端 需要 访问 文件 .giVinfo/refs 获 取 当 前 版 本 库 的 引用 列表 ， 并 
根据 引用 对 应 的 提交 ID 直接 访问 对 象 库 目 永 下 的 文件 。 如 果 对 象 文件 
被 打包 而 不 是 以 松散 对 象形 式 存 在 ， 则 Git 客 户 端 还 要 去 访问 文 
件 .git/objects/info/packs 以 获得 打包 文件 列表 ， 并 据 此 读 取 完整 的 打包 
文件 ， 从 打包 文件 中 获取 对 象 。 由 此 可 见 哑 协议 的 效率 非常 之 低 ， 甚 

会 因为 要 获取 一 个 对 象 而 去 访问 整个 pack 包 。 


使 用 哑 协 议 最 直观 的 感受 是 :传输 速度 非常 慢 ， 而 且 传 输 进 度 不 
可 见 ， 不 知道 什么 时 候 才 能 够 完成 数据 传输 。 上 述 协 议 中 ，FTP 和 
RSYNC 都 是 哑 协 议 ， 没 有 通过 git-http-backend 或 类 似 CGI 程 序 配置 的 
HTTP 服 务 句 提供 的 也 是 呈 协 议 。 因 为 吗 协 议 需 要 索引 文件 .git/info/refs 
和 .git/objects/info/packs 以 获取 引用 和 包 列 表 ， 因 此 要 在 版 本 库 的 钩子 
脚本 post-update 中 设置 运行 git update-server-info 以 确保 及 时 更 新 哑 协 议 


需要 的 索引 文件 。 不 过 如 果 不 使 用 哑 协 议 ， 运 行 git update-server-info 
束 没 有 什么 必要 了 。 


以 Git 项 目 本 喘 为 例 ， 看 看 如 何 使 用 不 同 的 协议 地 址 进行 版 本 库 殉 


GIT 协 议 《智能 协议 ) : 

$git clone git://git,.kernel.org/pub/scm/git/git.git 
HTTP (S) 哑 协 议 : 

$git clone http://www.kernel.org/pub/scm/git/git.git 
HTTP (S) 智能 协议 站: 


$git clone https://github.com/git/git.git 


[1] 使 用 Git 1.6.6 或 更 高 版 本 访问 。 


15.2 ”多 用 户 协 同 的 本 地 模拟 


在 本 篇 的 学 习 过 程 中 ， 需 要 一 个 能 够 提供 多 人 访问 的 版 本 库 ， 显 
然 要 找到 一 个 公共 服务 器 ， 并 且 能 让 所 有 人 都 尽情 发 挥 不 太 容 易 ， 但 
幸好 可 以 使 用 本 地 协议 来 模拟 。 在 后 面 的 内 容 中 ， 会 经 常 使 用 本 地 协 
议 地 址 fe:///path/to/repos/ 之 project> .git 来 代表 对 某 一 公共 版 本 库 的 访 
问 ， 您 可 以 把 fle:/ 格 式 的 URL 〈 比 直接 使 用 路 径 方式 更 逼真 ) 想象 为 
git:// 或 http:// 格 式 ， 并 且 想 象 它 是 在 一 台 远 程 的 服务 器 上 ， 而 非 本 机 。 


同样 地 ， 为 了 模拟 多 人 的 操作 ， 也 不 再 使 用 /path/to/my/workspace 
作为 工作 区 ， 而 是 分 别 使 用 /path/to/user1/workspace 
和 /path/to/user2/workspace 等 路 径 来 代表 不 同 用 户 的 工作 环境 。 同 样 想 
象 /path/to/user1/ 和 /path/to/user2/ 是 在 不 同 的 主机 上 ， 并 由 不 同 的 用 户 
进行 操作 。 


下 面 葡 来 演示 一 个 共享 版 本 库 的 搭建 过 程 ， 以 及 两 个 用 户 user1 和 
user2 在 各 目的 工作 区 中 是 如 何 工作 并 进行 数据 交换 的 ， 具 体 过 程 如 
下 。 


(1) 于 /path/to/repos/shared.git 中 创建 一 个 共享 的 版 本 库 。 


别 生 了 在 第 2 篇 的 "第 13 章 Git 殉 隆 ” 一 章 中 介绍 的 ， 以 裸 版 本 库 方 
式 创 建 。 


$git init--bare/path/to/repos/shared.git 
Initialized empty Git repository in/path/to/repos/shared.git/ 


(2) 用 户 user1l 克 隆 版 本 库 。 


从 下 面 的 命令 输出 可 以 看 出 ， 殉 隆 一 个 刚刚 初始 化 完成 的 裸 版 本 
车 会 显示 一 个 警告 ， 警 告 正在 克隆 的 版 本 库 是 一 个 空 版 本 库 。 


$cd/path/to/user1i/workspace 

$git clone file:///path/to/repos/shared.git project 
Cloning into project... 

warning:You appear to have cloned an empty repository. 


(3) 设置 username 和 useremail 配 置 变 量 。 


要 在 版 本 库 级 别 设置 username 和 useremail 配 置 变量 ( 即 运行 git 
config 命 令 时 不 使 用 --global 或 --system 参 数 ) ， 以 便 和 全 局 设置 区 分 
开 ， 因 为 我 们 的 模拟 环境 中 所 有 用 户 都 共享 同一 全 局 设置 和 系统 设 
置 o 


$cd project 
$git config user.name USser1I 
$git config user.email user1iQ@sun.ossxp.com 


(4) 用 户 user1 创 建 初始 数据 并 提交 。 


$echo Hello.>README 

$git add README 

$git commit-m "initial commit." 
[master(root-commit)5174bf3]initial commit. 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 README 


(5) 用 户 user1 将 本 地 版 本 库 的 提交 推送 到 上 游 。 


在 下 面 的 推送 指令 中 使 用 了 origin 别 名 ， 其 实际 指 同 就 是 
file:///path/to/repos/shared.git。 可 以 从 .git/config 配 置 文件 中 看 到 是 如 何 
实现 对 origin 远 程 版 本 库 注 册 的 。 关 于 远程 版 本 库 的 内 容 将 在 第 19 章 介 


绍 。 


$git push origin master 

Counting objects:3,done. 

Writing objects:100%(3/3),210 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(3/3),done. 

To file:///path/to/repos/shared.git 

*[new branch]master-~>master 


(6) 用户 user2 克 隆 版 本 库 。 


用 户 user2 殉 隆 时 没有 显示 警告 ， 因 为 此 时 共 圣 版 本 库 已 不 再 是 空 
版 本 库 了 。 


$cd/path/to/user2/workspace 

$git clone file:///path/to/repos/shared.git project 
Cloning into project... 

remote:Counting objects:3,done. 

remote:Total 3(delta 0),reused 0(delta 0) 

Receiving objects:100%(3/3),done. 


(7) 同样 在 user2 的 本 地 版 本 库 中 ， 设 置 username 和 useremail 配 
置 变量 ， 以 区 别 全 局 配置 设置 。 


$cd/path/to/user2/workspace/project 
$git config user.name user2 
$git config user.email user2@moon.ossxp.com 


(8) 用 户 user2 的 本 地 版 本 库 现在 拥有 和 user1 用 户 同样 的 提交 。 


$git log 

commit 5174bf33ab31a3999a6242fdcb1ec237e8f3f91a 
Author:user1i<user1i@sun.ossxp.com> 

Date:Sun Dec 19 15:52:29 2010+0800 

initial commit. 


15.3 ”强制 非 快 进 式 推送 


现在 用 户 user1 和 user2 的 工作 区 征 相 同 的 。 思 考 一 个 问题 : 如 果 两 
人 各 目 在 本 地 版 本 库 中 进行 独立 的 提交 ， 然 后 再 分 别 回 共 宇 版 本 库 推 
送 ， 会 互相 覆 兰 么 ? 为 了 回答 这 个 问题 ， 进 行 下 面 的 实践 。 


目 和 完 ， 用 户 user1 先 在 本 地 版 本 库 中 进行 提交 ， 然 后 将 本 地 的 提交 
推送 到 “远程 ” 共 至 版 本 库 中 ， 操 作 步 又 如 下 。 


(1) 用 户 user1 创 建 team/user1.txt 文 件 。 


假设 这 个 项 目 约 定 : 每 个 开发 者 在 team 目 录 下 写 一 个 自述 文件 。 
于 是 用 户 user1 创 建文 件 team/userl.txt 。 


$cd/path/to/user1i/workspace/project/ 

$mkdir team 

$echo "I'm user1."> team/user1.txt 

$git add team 

$git commit-m "user1's profile." 

[master b4f3ae0]user1'Ss profile. 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 team/user1.txt 


(2) 用 户 user1 将 本 地 提交 推送 到 服务 器 上 。 


$git push 

Counting objects:5, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 


Writing objects:100%(4/4),327 bytes, done. 
Total 4(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(4/4),done. 

To file:///path/to/repos/shared.git 
5174bf3. .b4f3ae0 master->master 


(3) 查看 当前 user1 版 本 库 中 的 日 志 。 


$git 1og--oneline--graph 
*b4f3ae0 User1's profile. 
*5174bf3 Initial commit. 


通过 上 面 的 操作 步 又， 可 以 看 到 用 户 user1 成 功 地 更 新 了 “远程 ? 共 
享 版 本 库 。 如 果 用 户 user2 不 知道 用 户 user1 所 做 的 上 述 操作 ， 仍 在 基 
于 “远程 ”版 本 库 旧 数据 同步 而 来 的 本 地 版 本 库 中 进行 改动 ， 然 后 用 户 
user2 问 “远程 ?共享 版 本 库 推 送 ， 会 有 什么 结果 呢 ? 用 下 面 的 操作 验证 
二 


(1) 用 户 user2 创 建 team/user2.txt 文 件 。 


$cd/path/to/user2/workspace/project/ 

$mkdir team 

$echo "I'm user1?"> team/user2.txt 

$git add team 

$git commit-m "user2's profile." 

[master 8409e4cl]user2's profile. 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 team/user2.txt 


(2) 用 户 user2 将 本 地 提交 推送 到 服务 器 时 出 错 。 


$git push 


To file:///path/to/repos/shared.git 

![rejected]jmaster->master(non-fast-forward ) 

error:failed to push some refs to 
‘file:///path/to/repos/shared.git' 

To prevent you from losing history,non-fast-forward updates were 
rejected 

Merge the remote changes(e.g.'git pull')before pushing again.See 
the 

'Note about fast-forwards' section of'git push--help'for 
details. 


(3) 将 用 户 user2 推 送 失败 的 错误 日 志 翻 译 如 下 : 


到 版 本 库 file:///path/to/repos/shared.git 
! [被 拒绝 ]master- >master( 非 快 进 ) 
错误 :部 分 引用 向 'file:///path/Vto/repos/shared .git ' 推 送 失败 
为 防 上 上 您 天 历史 数据 , 非 快 进 式 更 新 被 拒绝 。 
在 推送 前 请 先 合并 远程 改动 , 例如 执行 'git pull'。 


用 户 user2 推 送 失 败 了 。 但 这 不 是 坏事 ， 反 倒是 一 件 好 事情 ， 因 为 
这 避免 了 用 户 提 交 的 相互 覆盖 。Git 通 过 检查 推送 操作 是 不 是 “ 快 进 
式 ” 的 操作 ， 从 而 保证 用 户 的 提交 不 会 相互 覆盖 。 一 般 情 况 下 ， 推 送 只 
允许 “ 快 进 式 ?推送 。 所 谓 快 进 式 推送 ， 网 是 要 推送 的 本 地 版 本 库 的 提 
交 是 建立 在 远程 版 本 库 相 应 分 支 的 现 有 提交 基础 上 的 ， 即 远程 版 本 库 
相应 分 文 的 最 新 提交 十 本 地 版 本 库 最 新 提交 的 祖先 提交 。 但 现在 用 户 
user2 执 行 的 推送 并 非 如 此 ， 是 一 个 非 快 进 式 的 推送 。 


此 时 用 户 user2 本 地 版 本 库 的 最 新 提交 及 其 历史 提交 可 以 用 git rev- 
list 命 令 显 示 ， 如 下 所 示 : 


$git rev-list HEAD 
8409e4c72388ali8ea89eecb86d68384212c5233f 


5174bf33ab31a3999a6242fdcb1ec237e8f3f91a 


用 git ls-remote 命 令 显 示 远 程 版 本 库 的 引用 对 应 的 SHA1 哈 希 值 ， 
会 发 现 远 程 版 本 库 所 包含 的 最 新 提交 的 SHA1 哈 希 值 是 b4f3ae0.…… 
不 是 本 地 最 新 提交 的 祖先 提交 。 


$git ls-remote origin 
b4f3aeofcadce8c343f3cdc8a69c33cc98c98dfd HEAD 
b4f3aeofcadce8c343f3cdc8a69c33cc98c98dfd refs/heads/master 


实际 上 当 用 户 user2 执 行 推送 的 时 候 ，Git 就 是 利用 类 似 方 法 判断 出 
当前 的 推送 不 是 一 个 快 进 式 推送 ， 于 是 产生 警告 并 终止 。 


那么 如 何 才 能 成 功 推送 呢 ? 一 个 不 一 定 正确 的 解决 方案 是 : 强制 
推送 。 


在 推送 命令 的 后 面 使 用 -f 参 数 可 以 进行 强制 推送 ， 即 使 是 非 快 进 
式 的 推送 也 会 成 功 执行 。 用 户 user2 执 行 强制 推送 ， 会 强制 刷新 服务 器 
中 的 版 本 。 


$git push-f 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(3/3),done. 

Writing objects:100%(7/7),503 bytes, done. 

Total 7(delta 0),reused 3(delta 0) 

Unpacking objects:100%(7/7),done. 

To file:///path/to/repos/shared.git 
+b4f3ae0...8409e4c master->master(forced update) 


注意 到 了 么 ， 在 强制 推送 的 最 后 一 行 输出 中 显示 了 “强制 更 新 
(forced update) ”字样 。 这 样 用 户 userl 回 版 本 库 推 送 的 提交 由 于 用 户 
user2 的 强制 推送 被 履 盖 了 。 实 际 上 在 这 种 情况 下 userl 也 可 以 强制 推 
送 ， 从 而 用 上 自己 (user1) 的 提交 再 去 覆盖 用 户 user2 的 提交 。 这 样 的 工 
作 模 式 不 是 协同 ， 而 是 战争 ! 


在 上 面 用 户 user2 使 用 非 快 进 式 推送 强制 更 靳 版 本 库 ， 实 际 上 是 危 
险 的 。 滥 用 非 快 进 式 推 送 可 能 造成 提交 禾 盖 大 战 (战争 是 霸权 的 小 
用 ) 。 正 确 地 使 用 非 快 进 式 推送 ， 应 该 是 在 不 会 造成 提交 和 履 盖 “ 战 
争 ” 的 前 提 下 ， 对 历史 提交 进行 修补 。 


下 面 的 操作 也 许 十 一 个 使 用 非 快 进 式 推 送 的 更 好 的 例子 。 


(1) 用 户 user2 改 正之 前 错误 的 录入 。 


细心 的 读者 可 能 已 经 发 现 ， 用 户 user2 在 创建 个 人 描述 的 文件 中 把 
自己 的 名 字 写 错 了 。 假 设 用 户 user2 在 刚刚 完成 回 服务 器 的 推送 操作 后 
也 发 现 了 这 个 错误 ， 于 是 user2 进 行 了 下 面 的 更 改 。 


$echo "I'm user2."> team/user2.txt 

$git diff 

diff--git a/team/user2.txt b/team/user2.txt 
index 27268e2..2dcb7b6 100644 
---aA/team/user2.txt 

+++b/team/user2.txt 

QQ@-1+1@@ 

-I'm USer1? 

+I'm USer2. 


(2) 然后 用 户 user2 将 修改 好 的 文件 提交 到 本 地 版 本 库 中 。 


采用 直接 提交 还 是 使 用 修补 式 提交 ， 这 是 一 个 问题 。 因 为 前 次 的 
是 交 已 经 被 推送 到 共享 版 本 库 中 ， 如 果 采 用 修补 提交 会 造成 前 一 次 提 
交 被 新 提交 抹 掉 ， 从 而 在 下 次 推送 时 造成 非 快 进 式 推送 。 这 时 用 户 
user2 就 要 评估 “战争 ”的 风险 :“ 我 刚刚 推送 的 提交 ， 有 没有 可 能 被 其 他 
人 获取 了 (通过 git pull、git fetch 或 git clone 操 作 ) ? ”如 果 确 认 不 会 有 
他 人 获取 ， 例 如 现在 公司 里 只 有 user2 自 己 一 个 人 在 加 班 ， 那 么 可 以 放 
心地 进行 修补 操作 。 


$git add-u 

$git commit--amend-m "user2's profile." 
[master 6b1a7a0]user2 's profile. 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 team/user2.txt 


(3) 采用 强制 推送 ， 更 新 远程 共享 版 本 库 中 的 提交 。 这 个 操作 越 
早 越 好 ， 在 他 人 还 没有 来 得 及 和 服务 器 同步 前 将 修补 提交 强制 更 独到 
服务 器 上 。 


$git push-f 

Counting objects:5, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 

Writing objects:100%(4/4),331 bytes, done. 

Total 4(delta 0),reused 0O(delta 0) 

Unpacking objects:100%(4/4),done. 

To file:///path/to/repos/shared.git 
+8409e4c.,.6b1a7a0 master->master(forced update) 


15.4 合并 后 推送 


理性 的 工作 协同 要 避免 非 快 进 式 推送 。 一 旦 回 服 务 套 推送 后 ， 如 
果 发 现 错误 ， 不 要 使 用 会 更 改 历史 的 操作 〈 变 基 、 修 补 提交 ) ， 而 是 
采用 不 会 改变 历史 提交 的 反 转 提交 等 操作 。 


如 果 在 向 服务 器 推送 过 程 中 ， 由 于 他 人 率先 推送 了 新 的 提交 导致 
曹 遇 到 非 快 进 式 推送 的 警告 ， 应 该 进行 如 下 操作 才 更 为 理性 : 执行 git 
pul 获 取 服 务 硕 端 最 新 的 提交 并 和 本 地 提交 进行 合并 ， 合 并 成 功 后 再 


例如 用 户 userl 在 推送 时 遇 到 了 非 快 进 式 推送 错误 ， 可 以 通过 如 下 
操作 将 本 地 版 本 库 的 修改 和 远程 版 本 库 的 最 新 提交 进行 合并 。 


(1) 用 户 user1 发 现 椎 送 遇 到 了 非 快 进 式 推送 。 


$cd/path/to/user1i/workspace/project/ 

$git push 

To file:///path/to/repos/shared.git 

![rejected]jmaster->master(non-fast-forward) 

error:failed to push some refs to 
‘file:///path/to/repos/shared.git' 

To prevent you from losing history,non-fast-forward updates were 
rejected 

Merge the remote changes(e.g.'git pull')before pushing again,See 
the 

'Note about fast-forwards' section of'git push--help'for 
details. 


(2) 用 户 userl 运 行 git pull 命 令 。 


命令 git pull 实 际 包含 两 个 动作 ， 获 取 远 程 版 本 库 的 最 新 提交 ， 以 
及 将 获取 到 的 远程 版 本 库 提交 与 本 地 提交 进行 合并 。 


$git pull 

remote:Counting objects:5,done. 
remote:Compressing objects:100%(2/2),done. 
remote:Total 4(delta 0),reused 0(delta 0) 
Unpacking objects:100%(4/4),done. 

From file:///path/to/repos/shared 
+b4f3ae0...6b1ia7a0 master->origin/master(forced update) 
Merge made by recursive， 

team/user2.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 team/user2.txt 


(3) 合并 之 后 ， 看 看 版 本 库 的 提交 关系 图 。 


合并 之 后 远程 服务 器 中 的 最 新 提交 6b1a7a0 成 为 当前 最 新 提交 ( 合 
并 提交 ) 的 父 提交 之 一 。 如 采 再 推送 ， 则 不 再 是 非 快 进 式 的 了 。 


$git 1og--graph--oneline 

*bccc620 Merge branch 'master' of file:///path/to/repos/shared 
人 

|1*6b1a7a0 user2's profile. 

*|b4f3ae0 User1's profile. 

I/ 

*5174bf3 initial commit. 


(4) 执行 git push 命 令 ， 成 功 完成 到 远程 版 本 库 的 推送 。 


$git push 
Counting objects:10, done. 


Delta _ compression using up to 2 threads. 
Compressing objects:100%(5/5),done. 
Writing objects:100%(7/7),686 bytes, done. 
Total 7(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(7/7),done. 

To file:///path/to/repos/shared.git 
6bia7a0. .bccc620 master->master 


15.5 目下 | 大 站 的 去 


非 快 进 式 推送 如 果 人 被 滥用 束 会 成 为 项 目的 灾难 : 
团队 成 员 之 间 的 提交 战争 取代 了 本 应 的 相互 协作 。 
造成 不 必要 的 神 突 ， 为 他 人 造成 麻烦 。 


在 提交 历史 中 引入 包含 修补 提交 前 后 两 个 版 本 的 怪异 的 合并 所 


Git 提 供 了 至 少 两 种 方式 对 非 快 进 式 推送 进行 限制 。 一 个 是 通过 版 
本 库 的 配置 ， 另 一 个 是 通过 版 本 库 的 钩子 脚本 。 


将 版 本 库 的 配置 变量 receive.denyNonFastForwards 设 置 为 tue 可 以 
禁止 任何 用 户 进 行 非 快 进 式 推 送 。 下 面 的 示例 中 ， 可 以 看 到 对 一 个 已 
经 预先 设置 为 禁止 非 快 进 式 推送 的 版 本 库 执 行 非 快 进 式 推送 操作 ， 将 
会 被 禁止 ， 即 使 使 用 强制 推送 操作 也 会 被 禁止 。 


(1) 更 改 服 务 器 版 本 库 /pathyto/repos/shared.git 的 配置 变量 。 


$git--git-dir=/path/to/repos/shared.git config\ 
receive.denyNonFastForwards true 


(2) 在 用 户 userl 的 工作 区 执行 重 置 操作 ， 以 便 在 后 面 执行 推送 
时 产生 非 快 进 式 推送 。 
$git reset--hard HEAD^1 
$git 1og--graph--oneline 


*b4f3ae0 user1's profile. 
*5174bf3 initial commit. 


(3) 用 户 userl 即 便 使 用 强制 推送 也 不 会 成 功 。 
在 出 错 信 息 中 看 到 服务 右 端 拒绝 执行 : [remote rejected]。 


$git push-f 

Total O(delta 0),reused 0O(delta 0) 

remote:error:denying non-fast-forward refs/heads/master(you 
should pull first) 

To file:///path/to/repos/shared.git 

![remote rejectedlmaster->master(non-fast-forward) 

error:failed to push some refs to 
'file:///path/to/repos/shared.git'" 


另外 一 个 方法 是 通过 钩子 脚本 进行 设置 ， 可 以 仅 对 某 些 情况 下 的 
非 快 进 式 推送 进行 限制 ， 而 不 是 不 分 青 红 时 日 地 一 概 拒绝 。 例 如 : 只 
对 部 分 用 户 进行 限制 ， 而 允许 特定 用 户 执行 非 快 进 式 推送 ， 或 者 允许 
某 些 分 文 可 以 进行 强制 提交 而 其 他 分 文 不 可 以 。 第 5 篇 第 30 章 会 介绍 
Gitolite 服 务 架设 ， 通 过 授权 文件 (实际 上 通过 版 本 库 的 update 钧 子 脚 
本 实现 ) 对 版 本 库 非 快 进 式 推送 做 出 更 为 精细 的 授权 控制 。 


上 一 但 介绍 了 Git 协议 ， 并 且 使 用 本 地 协议 来 模拟 一 个 远程 的 版 本 库 ， 以 两 个 不 同 用 户 
的 身份 检 出 该 版 本 库 ， 和 该 远程 版 本 库 进 行 交 互 一 一 交换 数据 、 协 同 工 作 。 在 上 一 章 的 协同 
中 只 过 到 了 一 个 小 小 的 麻烦 一 一 非 快 进 式 推送 ， 可 以 通过 执行 拉 回 操作 (git pul1l)， 成功 
完成 合并 后 青 推送 。 

但 是 在 真实 的 运行 环境 中 ， 用 户 间 协 同 并 不 总 是 会 一 帆 风 顺 ， 只 要 有 合并 就 可 能 会 有 剖 
突 。 本章 就 重点 介绍 冲突 解决 机 制 ， 


16.1 拉 回 操作 中 的 合并 


为 了 降低 难 座 ， 上 一 章 的 实践 中 用 户 userl 执行 git pull 操作 解决 非 快 进 式 推送 问 
题 似乎 非常 简单 ， 就 好 像 只 要 把 共享 版 本 库 中 的 最 新 提交 直接 拉 回 到 本 地 ， 然 后 就 可 以 推送 
了 ， 共 他 的 好 像 什么 都 没有 发 生 一 样 。 真 的 是 这 样 么 ? 

(1》 用 户 userl 向 共享 版 本 库 推送 时 ， 因 为 user2 强制 推送 已 经 改变 了 共享 版 本 库 中 的 
提交 状态 ， 导 致 userl 推送 失败 ， 如 图 16-1 所 示 ， 


用 户 Userl 本 她 禾 本 库 


图 16-1 非 快 进 式 推送 着 禁止 


(2) 用 户 userl 执行 拉 回 操作 的 第 一 阶段 ， 将 共享 版 本 库 master 分 支 的 最 新 提交 获 
取 到 本 地 ， 并 更 新 到 本 地 版 本 库 特 定 的 引用 refs/remotes/origin/master (简称 为 
origin/master)， 如 图 16-2 所 示 ， 


用 办 userl 本 她 版本 库 


图 16-2 执行 获取 操作 


(3) 用 户 userl 执 行 拉 回 操 作 的 第 二 阶段 ， 将 本 地 分 文 master 和 共 
享 版 本 库 本 地 跟踪 分 支 origin/master 进 行 合 并 操作 ， 如 图 16-3 所 示 。 


onigin/maater master | mastor 
日 
herpe 
用 户 userl 本 地 版 本 库 \ 间 享 版 本 库 


图 16-3 执行 合并 操作 


(4) 用 户 user1 执 行 推送 操作 ， 将 本 地 提交 推送 到 共享 版 本 库 
中 ， 如 图 16-4 所 示 。 


master master 


AR git push CC 下 
-一 一 -一 一 一 二 | 本 二 
2 8 CY x0) 


用 户 user! 本 地 版 本 库 | 共享 版 本 库 
16-4 执行 推送 操作 


实际 上 拉 回 操作 (git pull) 是 由 两 个 步骤 组 成 的 : 一 个 是 获取 操 
作 (gitfetch) ， 另 一 个 是 合并 操作 (git merge) ， 即 : 


git pull=git fetch+git merge 


图 16-2 示 意 的 获取 操作 看 似 很 简单 ， 实 际 上 要 到 第 19 草 介绍 远程 
版 本 库 的 章节 才能 够 讲 明 白 ， 现 在 只 需要 根据 图 示 将 获取 操作 理解 为 


将 远程 的 共享 版 本 库 的 对 象 提交、 里 程 碑 、 分 支 等 ) 复制 到 本 地 即 
可 。 


合并 操作 是 本 章 要 介绍 的 重点 。 合 并 操作 可 以 由 拉 回 操作 (git 
pull) 隐 式 地 执行 ， 将 其 他 版 本 库 的 提交 和 本 地 版 本 库 的 提交 进行 合 
并 。 还 可 以 针对 本 版 本 库 中 的 其 他 分 支 (将 在 第 18 革 中 介绍 ) 进行 显 
示 的 合并 操作 ， 将 其 他 分 文 的 提交 和 当前 分 文 的 提交 进行 合并 。 


合并 操作 的 命令 行 格式 如 下 : 
git merge[ 选 项 ...]<commit>... 


合并 操作 的 大 多 数 情况 ， 只 须 提供 一 个 <commit> (提交 ID 或 对 
应 的 引用 : 分 支 、 里 程 碑 等 ， 作 为 参数 。 合 并 操作 将 < commit> 对 应 
的 目录 树 和 当前 工作 分 文 的 目 永 树 的 内 容 进 行 合 并 ， 合 并 后 的 提交 以 
当前 分 文 的 提交 作为 第 一 个 父 所 区 ， 以 <commit> 为 第 二 个 父 提 交 。 
合并 操作 还 支持 将 多 个 < commit> 代表 的 分 支 和 当前 分 支 进行 合并 ， 
过 程 类 似 。 


默认 情况 下 ， 合 并 后 的 结 末 会 目 动 提交 ， 但 是 如 果 提 供 --no- 
commit 选 项 ， 则 合并 后 的 结 末 会 放 入 暂 存 区 ， 用 户 可 以 对 合并 结 采 进 
行 检 查 、 更 改 ， 然 后 手动 提交 。 


合并 操作 并 非 总 会 成 功 ， 因 为 合并 的 不 同 提交 可 能 同时 修改 了 同 
一 文件 相同 区 域 的 内 容 ， 导 致 冲 突 。 神 突 会 造成 合并 操作 的 中 断 ， 神 
突 的 文件 被 标 识 ， 用 户 可 以 对 标识 为 冲突 的 文件 进行 冲突 解决 操作 ， 
然后 更 狐 暂 存 区 ， 青 提交， 最终 完 成 合并 操作 。 


根据 合并 操作 是 否 遇 到 冲突 ， 以 及 不 同 的 冲突 类 型 ， 可 以 分 为 以 
下 几 种 情况 : 成功 的 目 动 合 并 、 人 逻辑 冲突 、 真 正 的 冲突 和 树 冲突 。 下 
面 分 别 予 以 介绍 。 


16.2 ”合并 一 : 目 动 合并 

Git 的 合并 操作 非常 智能 ， 大 多 数 情 况 下 会 目 动 完成 合并 。 不 管 是 
修改 不 同 的 文件 ， 还 是 修改 相同 的 文件 (文件 的 不 同位 置 ) ， 或 者 文 
件 名 变更 。 


16.2.1 ”修改 不 同 的 文件 


如 有 果 用 户 user1 和 user2 各 目的 本 地 提交 中 修改 了 不 同 的 文件 ， 当 一 
个 用 户 将 改动 推送 到 服务 器 后 ， 男 外 一 个 用 户 推 送 束 会 遇 到 非 快 进 式 
推送 错误 ， 需 要 先 合并 再 推送 。 因 为 两 个 用 户 修 改 了 不 同 的 文件 ， 合 
并 不 会 遇 到 麻烦 。 


在 上 一 草 的 操作 过 程 中 ， 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 可 
能 不 一 致 ， 为 了 确保 版 本 库 状 态 的 一 致 性 ， 以 便 下 面 的 实践 能 够 正 稼 
执行 ， 分 别 在 两 个 用 户 的 本 地 版 本 库 中 执行 下 面 的 操作 。 


$git fetch 

$git reset--hard origin/master 

下 面 的 实践 中 ， 两 个 用 户 分 别 修改 不 同 的 文件 ， 其 中 一 个 用 户 要 
答 试 合并 操作 将 本 地 提交 和 另外 一 个 用 户 的 提交 合并 ， 有 具体 操作 过 程 
如 下 。 


(1) 用 户 user1l 修 改 teamy/userl.txt 文 件 ， 提 交 并 推送 到 共享 服务 


口 恒 


五 计 2 


$cd/path/to/user1i/workspace/project/ 

$echo "hack by user1 atdate">~>team/user1.txt 
$git add-u 

$git commit-m "update team/useri1.txt" 

$git push 


(2) 用 户 user2 修 改 teamyuser2.txt 文 件 ， 提 交 。 


$cd/path/to/user2/workspace/project/ 

$echo "hack by user2 atdate">~>team/user2.txt 
$git add-u 

$git commit-m "update team/user2.txt" 


(3) 用 户 user2 在 推送 的 时 候 ， 会 遇 到 非 快 进 式 推送 的 错误 而 被 
终 让 坟 


$git push 

To file:///path/to/repos/shared.git 

![rejectedljmaster->master(non-fast-forward) 

error:failed to push some refs to 
‘file:///path/to/repos/shared.git' 

To prevent you from losing history,non-fast-forward updates were 
rejected 

Merge the remote changes(e.g.'git pull')before pushing again,.See 
the 

"Note about fast-forwards'section of 'git push--help' for 
details ， 


(4) 用 户 user2 执 行 获取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 
本 地 用 于 跟踪 共享 版 本 库 master 分 支 的 本 地 引用 origin/master 中 。 


$git fetch 

remote:Counting objects:7,done. 
remote:Compressing objects:100%(4/4),done. 
remote:Total 4(delta 0),reused 0(delta 0) 
Unpacking objects:100%(4/4),done. 

From file:///path/to/repos/shared 

bccc620. ,25fce74 master->origin/master 


(5) 用 户 user2 执 行 合并 操作 ， 完 成 自动 合并 。 


$git merge origin/master 

Merge made by recursive. 

team/user1.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 


(6) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 


$git push 

Counting objects:12,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(7/7),done. 
Writing objects:100%(7/7),747 bytes, done. 
Total 7(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(7/7),done. 

To file:///path/to/repos/shared.git 
25fce74. .0855b86 master->master 


(7) 通过 提交 日 志 ， 可 以 看 到 成 功 合并 的 提交 及 其 两 个 父 
关系 图 * 


$git 10g-3--graph--stat 

*commit 0855b86678d1cf86ccdd13adaaa6e735715d6a7e 
|\Merge:f53acdf 25fce74 

| |Author:user2<user2Q@moon.ossxp.com> 

||Date:Sat Dec 25 23:00:55 2010+0800 
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Merge remote branch 'origin/master' 
g g 


| 

*commit 25fce74b5e73b960c42e4a463d03d462919b674d 
Author:user1i<useri@sun.ossxp.com> 

Date:Sat Dec 25 22:54:53 2010+0800 


update team/user1.txt 


team/user1.txt|1+ 
1 files changed,1 insertions(+),0 deletions(-) 


*|commit f53acdf6a76e0552b562f5aaa4d40ff19e8e2f77 
|/Author:user2<user2Q@moon.ossxp.com> 

|Date:Sat Dec 25 22:56:49 2010+0800 

| 


|update team/user2.txt 


|team/user2.txt|1+ 
|1 files changed,1 insertions(+),0©0 deletions(-) 


16.2.2 ”修改 相同 文件 的 不 同 区 域 


当 用 户 user1 和 user2 在 本 地 提交 中 修改 相同 的 文件 ， 但 是 修改 的 十 
文件 的 不 同位 置 时 ， 则 两 个 用 户 的 提交 仍 可 成 功 合并 ， 有 具体 操作 过 程 
如 下 。 


(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 先 分 
别 对 两 个 用 户 的 本 地 版 本 库 执 行 拉 回 操作 。 


$git pull 


(2) 用 户 user1 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 
第 一 行 插入 内 容 ， 更 改 后 的 文件 内 容 如 下 。 


User1 hacked . 
Hello. 


(3) 用 户 user1 对 修改 进行 本 地 提交 并 推送 到 共享 版 本 库 。 


$git add-u 
$git commit-m "User1 hack at the beginning." 
$git push 
(4) 用 户 user2 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 
最 后 插入 内 容 ， 更 改 后 的 文件 内 容 如 下 。 


Hello. 
User2 hacked. 


(5) 用 户 user2 对 修改 进行 本 地 提交 。 


$git add-u 
$git commit-m "User2 hack at the end." 


(6) 用 户 user2 执 行 获取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 
本 地 用 于 跟踪 共 译 版 本 库 master 分 支 的 本 地 引用 origin/master 中 。 


$git fetch 

remote:Counting objects:5,done. 
remote:Compressing objects:100%(2/2),done. 
remote:Total 3(delta 0),reused 0(delta 0) 
Unpacking objects:100%(3/3),done. 

From file:///path/to/repos/shared 

0855b86. .07e9d08 master->origin/master 


(7) 用 户 user2 执 行 合并 操作 ， 完 成 自动 合并 。 


$git merge refs/remotes/origin/master 
Auto-merging README 

Merge made by recursive., 

README | 1+ 

1 files changed,1 insertions(+),0 deletions(-) 


(8) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 


$git push 

Counting objects:10,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(4/4),done. 
Writing objects:100%(6/6),607 bytes, done. 


Total 6(delta 0),reused 3(delta 0) 
Unpacking objects:100%(6/6),done. 
To file:///path/to/repos/shared.git 
07e9d08. .2a67e6f master->master 


(9) 如 果 追 洲 一 下 README 文 件 每 一 行 的 来 源 ， 可 以 看 到 分 别 
是 user1 和 user2 更 改 的 最 前 和 最 后 的 一 行 。 


$git blame README 

OQ7e9d082(user1 2010-12-25 23:12:17+0800 1)User1 hacked. 
A5174bf3(user1 2010-12-19 15:52:29+0800 2)Hello. 
bboc74fa(user2 2010-12-25 23:14:27+0800 3)User2 hacked ， 


16.2.3 ”同时 更 改 文件 名 和 文件 内 容 


如 果 一 个 用 户 将 文件 移动 到 其 他 目录 (或 修改 文件 名 ) ， 另 外 一 
个 用 户 针对 重 命名 前 的 文件 进行 了 修改 ， 还 能 够 实现 目 动 合并 么 ? 这 
对 于 其 他 版 本 控制 系统 可 能 是 一 个 难题 ， 例 如 Subversion 就 不 能 很 好 地 
处 理 ， 还 为 此 引入 了 一 个 “ 树 冲 突 * 的 新 名 词 。Git 对 于 此 类 冲突 能 够 很 
好 地 处 理 ， 可 以 目 动 解决 冲突 实现 目 动 合并 ， 具 体操 a 作 过 程 如 下 。 


(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 先 分 
别 对 两 个 用 户 的 本 地 版 本 库 执 行 拉 回 操作 。 


$git pull 


(2) 用 户 userl 在 自己 的 工作 区 中 将 文件 README 进 行 重 命名 ， 
本 地 提交 并 推送 到 共享 版 本 库 。 
$cd/path/to/user1i/workspace/project/ 
$mkdir doc 
$git mv README doc/README. txt 
$git commit-m "move document to doc/." 
$git push 


(3) 用 户 user2 在 自己 的 工作 区 中 修改 README 文 件 ， 在 文件 的 
最 后 插入 内 容 ， 并 本 地 提交 。 


$cd/path/to/user2/workspace/project/ 


$echo "User2 hacked again."> >README 
$git add-u 
$git commit-m "User2 hack README again." 


(4) 用 户 user2 执 行 获 取 (git fetch) 操作 。 获 取 到 的 提交 更 新 到 
本 地 跟踪 共享 版 本 库 master 分 支 的 本 地 引用 origin/master 中 。 


$git fetch 

remote:Counting objects:5,done. 
remote:Compressing objects:100%(2/2),done. 
remote:Total 3(delta 0),reused 0(delta 0) 
Unpacking objects:100%(3/3),done. 

From file:///path/to/repos/shared 

0855b86. .07e9d08 master->origin/master 


(5) 用 户 user2 执 行 合并 操作 ， 完 成 自动 合并 。 


$git merge refs/remotes/origin/master 

Merge made by recursive. 

README= > doc/README. txt|0 

1 files changed,0 insertions(+),0 deletions(-) 
rename README=> doc/README .txt(100%) 


(6) 用 户 user2 推 送 合并 后 的 本 地 版 本 库 到 共享 版 本 库 。 


$git push 

Counting objects:10, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(5/5),done. 
Writing objects:100%(6/6),636 bytes, done. 
Total 6(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(6/6),done. 

To file:///path/to/repos/shared.git 
9c51cb9,. .f73db10 master->master 


(7) 使 用 -m 参 数 可 以 查看 合并 操作 所 做 出 的 修改 。 


$git 1og-1-m--Stat 

commit f73db106c820fgoc6d510f18ae8c67629af9c13b7(from 
887488eee19300c566c272ec84b 236026b0303c6 ) 

Merge:887488e 9c51cb9 

Author:user2<user2@moon.ossxp.com> 

Date:Sat Dec 25 23:36:57 2010+0800 

Merge remote branch 'refs/remotes/origin/master' 

README|4---- 

doc/README .txt |4++++ 

2 files changed,4 insertions(+),4 deletions(-) 

commit f73db106c820fOc6d510f1i8ae8c67629af9c13b7(from 
9c51cb91bfe12654e2de1d61d72 2161db0539644) 

Merge:887488e 9c51cb9 

Author:user2<user2@moon.ossxp.com> 

Date:Sat Dec 25 23:36:57 2010+0800 

Merge remote branch 'refs/remotes/origin/master' 

doc/README .txt | + 

1 files changed,1 insertions(+),0 deletions(-) 


16.3 合并 二 : 逻辑 冲突 


目 动 合并 如 条 成 功 地 执行 ， 则 大 多 数 情况 下 束 意 味 着 完事 大 吉 ， 
但 是 在 某 些 特殊 情况 下 ， 合 并 后 的 结果 虽然 在 Git 看 来 是 完美 的 合并 ， 
实际 上 却 存在 着 逻辑 冲突 。 


一 个 典型 的 逻辑 冲突 钙 一 个 用 户 修 改 了 一 个 文件 的 文件 名 ， 而 男 
外 的 用 户 在 其 他 文件 中 引用 旧 的 文件 名 ， 这 样 的 合并 虽然 能 够 成 功 但 
是 包含 着 逻辑 冲突 。 例 如 : 


(1) 一 个 Cc 语言 的 项 目 中 存在 头 文件 hello.h， 该 头 文件 定义 了 一 
些 画 数 声明 。 


(2) 用 户 user1 将 hello.h 文 件 改 名 为 api.h 。 


(3) 用 户 user2 写 了 一 个 新 的 源码 文件 foo.c 并 在 该 文件 中 包含 了 
hello.h 文 件 。 


(4) 两 个 用 户 的 提交 合并 后 ， 会 因为 源码 文件 foo.c 找 不 到 所 包含 
的 文件 hello.h 而 导致 项 目 编译 失败 。 


再 举 一 个 逻辑 冲突 的 示例 。 假 如 一 个 用 户 修 改 函 数 返 回 值 而 帮 
外 的 用 户 使 用 旧 的 函数 返回 值 ， 虽 然 成 功 合并 但 是 存在 逻辑 冲突 : 


(1) 函数 compare (obj1，obj2) 用 于 比较 两 个 对 象 obj1 和 obj2 。 
返回 1 代表 比较 的 两 个 对 象 相 同 ， 返 回 0 代表 比较 的 两 个 对 象 不 同 。 


(2) 用 户 user1 修 改 了 该 函数 的 返回 值 ， 返 回 0 代表 两 个 对 象 相 
同 ， 返 回 1 代 表 obj1 大 于 obj2， 返 回 -1 则 代表 obj1 小 于 obj2。 


(3) 用 户 user2 不 知道 user1 对 该 函数 的 改动 ， 仍 以 该 函数 原 返 回 
值 判断 两 个 对 象 的 有 异同。 


(4) 两 个 用 户 的 提交 合并 后 ， 不 会 出 现 编译 错误 ， 但 是 软件 中 会 
潜藏 看 重大 的 Bug。 


上 面 的 两 个 逻辑 冲突 的 示例 ， 尤 其 是 最 后 一 个 非常 难以 捕捉 。 如 
果 因 此 而 岂 低 Git 的 目 动 合并 ， 或 者 对 每 次 目 动 合并 的 结 采 疑 神 疑 兄 ， 
进而 花费 大 量 精力 去 分 析 合 并 的 结果 ， 则 是 因 吐 废 食 、 得 不 偿 失 。 
个 好 的 项 目 实践 是 每 个 开发 人 员 部 为 目 己 的 代码 编写 可 运行 的 单元 济 
试 ， 项 目 每 次 编译 时 都 要 执行 目 动 化 测试 ， 捕 捉 潜 产 的 Bug。 在 2010 
年 OpenParty 上 的 一 个 报告 中 ， 我 介绍 了 如 何在 项 目 中 引入 单元 测试 及 
目 动 化 集成 ， 可 以 参考 下 面 的 链接 : 


http:/www.beijing-open-party.org/topic/9 


http://wenku.baidu.com/view/63bf7d160b4e767f5acfcef6.html 


16.4 合并 三 : 冲突 解决 


如 果 两 个 用 户 修改 了 同一 文件 的 同一 区 域 ， 则 在 合并 的 时 候 会 遇 
到 冲突 而 导致 合并 过 程 中 断 。 这 是 因为 Git 并 不 能 越 租 代 万 地 兰 用 户 做 
出 决定 ， 而 古 把 决定 权 交 给 用 户 。 在 这 种 情况 下 ，Gits 标 识 出 合并 冲 
突 ， 等 每 用 户 对 冲突 做 出 抉择 。 


下 面 的 实践 非常 简单 ， 两 个 用 户 都 修改 dowREADME.txt 文 件 ， 在 
第 二 行 "Hello." 的 后 面 加 上 自己 的 名 字 ， 上 有 具体 操作 过 程 如 下 。 


(1) 为 确保 两 个 用 户 的 本 地 版 本 库 和 共享 版 本 库 状 态 一 致 ， 移 分 
别 对 两 个 用 户 的 本 地 版 本 库 执 行 拉 回 操作 。 


$git pull 


(2) 用 户 userl 在 自己 的 工作 区 中 修改 dowREADME.txt 文 件 〈 仅 
改动 了 第 二 行 ) 。 修 改 后 内 容 如 下 : 
User1 hacked. 
Hello,user1. 


User2 hacked. 
User2 hacked again. 


(3) 用 户 user1 对 修改 进行 本 地 提交 并 推送 到 共享 版 本 库 。 


$git add-u 
$git commit-m "Say hello to useri." 
$git push 


(4) 用 户 user2 在 自己 的 工作 区 中 修改 dowREADME.txt 文 件 〈 仅 
改动 了 第 二 行 ) 。 修 改 后 内 容 如 下 : 


User1 hacked. 
Hello, user2. 

User2 hacked. 

User2 hacked again. 


(5) 用 户 user2 对 修改 进行 本 地 提交 。 


$git add-u 
$git commit-m "Say hello to user2." 


(6) 用 户 user2 执 行 拉 回 操作 ， 通 到 冲突 。 
git pull 操 作 相 当 于 git fetch 和 git merge 两 个 操作 。 


$git pull 

remote:Counting objects:7,done. 

remote:Compressing objects:100%(3/3),done. 

remote:Total 4(delta 0),reused 0(delta 0) 

Unpacking objects:100%(4/4),done. 

From file:///path/to/repos/shared 

f73db10. .a123390 master->origin/master 

Auto-merging doc/README.txt 

CONFLICT(content):Merge conflict in doc/README. txt 
Automatic merge failed; fix conflicts and then commit the 


result. 


执行 git pull 时 所 做 的 合并 操作 由 于 遇 到 冲突 导致 中 断 。 来 看 看 处 
于 合并 冲突 状态 时 工作 区 和 和 暂 存 区 的 状态 。 


执行 git status 命 令 ， 可 以 从 状态 输出 中 看 到 文件 dowREADME.txt 

处 于 未 合并 (冲突 ) 的 状态 ， 这 个 文件 在 两 个 不 同 的 提交 中 都 做 了 修 
改 。 

$git status 

#0n branch master 

#Your branch and 'refs/remotes/origin/master' have diverged, 

#and have 1 and 1 different commit(s)each,respectively. 

# 

#Unmerged paths: 

#(USe "git add/rm<file>..." as appropriate to mark resolution) 

#both modified:doc/README.txt 


# 
no changes added to commit(use "git add" and/or "git commit-a") 


那么 Git 是 如 何 记录 合并 过 程 及 冲突 的 呢 ? 实际 上 合并 过 程 是 通 
过 .git 目 录 下 的 几 个 文件 进行 记录 的 : 


文件 .giWMERGE_HEAD 记 录 所 合并 的 提交 ID。 
文件 .giWMERGE_MSG 记 录 合 并 失败 的 信息 。 


文件 .giVMERGE_MODE 标 识 合 并 状态 。 


版 本 库 暂 存 区 中 则 会 记录 冲突 文件 的 多 个 不 同 版 本 。 可 以 使 用 git 


1s-files 命 令 查 看 : 


$git ls-files-s 

100644 ea501534d70a13b47b3b4b85c39ab487fa6471c2 
100644 5611db505157d312e4f6fb1db2e2c5bac2a55432 
100644 036dbc5c11b0agcefc8247cfoe9a3e678f8de060 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 


doc/README. txt 
doc/VREADME .七 Xt 
doc/README. txt 
team/user1.txt 
team/user2.txt 


OOONPc 


在 上 面 的 输出 中 ， 每 一 行 分 为 四 个 字段 ， 前 两 个 分 别 是 文件 的 属 
性 和 SHA1 哈 希 值 。 第 三 个 字段 十 暂 存 区 编号 。 当 合并 冲突 发 生 后 ， 会 
用 到 0 以 上 的 暂 存 区 编号 。 


编写 为 1 的 暂 存 区 用 于 保存 冲突 文件 修改 之 前 的 副本 ， 即 冲突 双方 
共同 的 祖先 版 本 。 可 以 用 :1:<fiename> 访 问 。 


$git show:1:doc/README. txt 
User1 hacked. 

Hello. 

User2 hacked. 

User2 hacked again. 


编号 为 2 的 暂 存 区 用 于 保存 当前 冲突 文件 在 当前 分 支 中 修改 的 副 
本 。 可 以 用 :2:<filename> 访 问 。 


$git show:2:doc/README. txt 
User1 hacked. 

Hello, user2. 

User2 hacked. 

User2 hacked again. 


编号 为 3 的 和 暂 存 区 用 于 保存 当前 冲突 文件 在 合并 版 本 (分 支 ) 中 修 
改 的 副本 。 可 以 用 :3:<fiename> 访 问 。 


$git show:3:doc/README. txt 
User1 hacked. 

Hello,user1. 

User2 hacked. 

User2 hacked again. 


对 暂 存 区 中 冲突 文件 的 上 述 三 个 副本 无 须 了 解 太 多 ， 这 三 个 副本 
实际 上 是 提供 冲突 解决 工具 ， 用 于 实现 三 同文 件 合并 的 。 


工作 区 的 版 本 则 可 能 同时 包含 了 成 功 的 合并 及 冲突 的 合并 ， 其 中 
冲突 的 合并 会 用 特殊 的 标记 (<<<<<<<=======>>>>>> 


>) 进行 标识 。 查 看 当前 工作 区 中 冲突 的 文件 : 


$cat doc/README.txt 
User1 hacked. 
<<<<<<<HEAD 
Hello, user2. 


Hello,useri. 
>>>>>>>al23390b8936882bd53033a582ab540850b6b5fb 
User2 hacked. 

User2 hacked again. 


特殊 标识 < < < < < < < (七 个 小 于 号 ) 和 ======= (七 个 等 
号 ) 之 间 的 内 容 是 当前 分 支 所 更 改 的 内 容 。 特 殊 标识 ======= (七 个 


等 号 ) 和 > > > > > > > (七 个 大 于 号 ) 之 间 的 内 容 是 所 合并 的 版 本 
更 改 的 内 容 。 


冲突 解决 的 实质 束 是 通过 编辑 操作 ， 将 神 究 标 识 符 所 标识 的 冲突 
内 容 蔡 换 为 合适 的 内 容 ， 并 去 掉 冲 突 标识 符 。 编 辑 完毕 后 执行 git add 


命令 将 文件 添加 到 暂 存 区 (标号 0) ， 然 后 再 提交 就 完成 了 冲突 解决 。 


当 工 作 区 处 于 合并 冲突 状态 时 ， 无 法 再 执行 提交 操作 。 此 时 有 两 
个 选择 :放弃 合并 操作 ， 或 者 对 合并 冲突 进行 冲突 解决 操作 。 放 弃 合 
并 操作 非常 简单 ， 只 须 执行 git reset 将 暂 存 区 重 置 即 可 。 下 面 重点 介绍 
如 何 进 行 冲突 解决 的 操作 。 有 两 个 方法 进行 冲突 解决 ， 一 个 是 对 少量 
冲突 非常 适合 的 手工 编辑 操作 ， 男 外 一 个 是 使 用 图 形 化 冲突 解决 工 
具 。 


一 


16.4.1 手工 编辑 完成 冲突 解决 


先 来 看 看 不 使 用 工具 ， 直 接手 动 编辑 完成 冲突 解决 。 打 开 文 件 
doc/README.txt， 将 冲突 标识 符 所 标识 的 文字 替换 为 Hello,userl and 
user2.。 修 改 后 的 文件 内 容 如 下 : 


User1 hacked. 
Hello,user1 and user2. 


User2 hacked. 
User2 hacked again. 


然后 添加 到 暂 存 区 ， 并 提交 : 


$git add-u 
$git commit-m "Merge completed:say hello to all users." 


查看 最 近 二 次 提交 的 日 志 ， 会 看 到 最 新 的 提交 就 古 一 个 合并 提 


$git 1Log--oneline--graph-3 

*bd3ad1a Merge completed:say hello to all users. 
人 

|*a123390 Say hello to User1I， 

*|60b10f3 Say hello to user2. 

I/ 


提交 完成 后 ， 会 看 到 .git 目 录 下 与 合并 相关 的 文 
件 .giVMERGE_HEAD、.giVMERGE_MSG、.giVMERGE_MODE 文 件 
都 自动 删除 了 。 


如 采 查 看 暂 存 区 ， 会 发 现 冲突 文件 在 暂 存 区 中 的 三 个 副本 也 都 清 
除了 (实际 在 对 编辑 完成 的 冲突 文件 执行 git add 后 就 已 经 清除 了 ) 。 


$git ls-files-s 

100644 463dd451d94832f196096bbcoc9cf9f2dof82527 0 doc/README .txt 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 


16.4.2 ”图 形 工具 完成 冲突 解决 


上 面 介绍 的 通过 手工 编辑 完成 冲突 解决 并 不 复杂 ， 对 于 简单 的 冲 
突 是 最 快捷 的 解决 方法 。 但 是 如 果 冲 突 的 区 域 过 多 、 过 大 ， 并 且 缺 乏 
原始 版 本 作为 参照 ， 神 突 解决 过 程 吕 会 显得 非常 的 不 便 ， 这 种 情况 下 
使 用 图 形 工具 吏 显 得 非常 有 优势 。 


AS 


还 以 上 面 的 合并 冲突 为 例 介绍 使 用 图 形 工具 进行 冲突 解决 的 方 
法 。 为 了 制造 一 个 冲突 ， 首 先 把 user2 辛 注 若 苦 完 成 的 冲突 解决 提交 回 
深 ， 再 执行 合并 重新 进入 冲突 状态 。 


(1) 将 冲突 解决 的 提交 丢弃 ， 即 强制 重 置 到 前 一 个 版 本 。 


$git reset--hard HEADA^ 


(2) 这 时 查看 状态 ,会 显示 当前 工作 分 支 的 最 新 提交 和 共享 版 本 
库 的 master 分 支 的 最 新 提交 出 现 了 偏离 。 


$git status 

#0n branch master 

#Your branch and 'refs/remotes/origin/master' have diverged, 
#and have 1 and 1 different commit(s)each,respectively. 

## 

nothing to commit(working directory clean) 


(3) 那么 执行 合并 操作 吧 。 冲 突 发 生 了 。 


$git merge refs/remotes/origin/master 

Auto-merging doc/README. txt 

CONFLICT(content):Merge conflict in doc/README. txt 

Automatic merge failed; fix conflicts and then commit the 
result. 


下 面 就 演示 使 用 图 形 工具 如 何 解决 冲突 。 使 用 图 形 工具 进行 冲突 
解决 需要 事先 在 操作 系统 中 安装 相关 的 工具 软件 ， 如 : kdiff3、meld、 
tortoisemerge、araxis 等 。 而 启动 图 形 工 具 进 行 冲突 解决 也 非常 简单 ， 


只 须 执行 命令 git mergetool 即 可 。 


$git mergetool 

merge tool candidates:opendiff kdiff3 tkdiff xxdiff meld 
tortoisemerge gvimdiff 

diffuse ecmerge p4merge araxis emerge vimdiff 

Merging: 

doc/README. txt 

Normal merge conflict for 'doc/README.txt': 

{local}:modified 

{remote}:modified 

Hit return to start merge resolution tool(kdiff3): 


运行 git mergetool 命 令 后 ， 会 显示 支持 的 图 形 工 具 列 表 ， 并 提示 用 
户 选择 可 用 的 冲突 解决 工具 。 默 认 会 选择 系统 中 已 经 安装 的 工具 软 
件 ， 如 kdiff3。 直 接 按 下 回 车 键 ， 目 动 打开 kdiff3 进 入 冲突 解决 界面 。 


启动 kdiff3 后 ， 如 图 16-5 所 示 ， 上 方 三 个 窗口 由 左 至 右 显示 冲突 文 
件 的 三 个 版 本 ， 分 别 是 : 


A: 暂 存 区 1 中 的 版 本 (共同 祖先 版 本 ) 。 


B: 暂 存 区 2 中 的 版 本 〈 当 前 分 支 更 改 的 版 本 ) 。 
C: 暂 存 区 3 中 的 版 本 (他 人 更 改 的 版 本 ) 。 


kdiff3 下 方 的 窗口 是 合并 后 文件 的 编辑 窗口 。 如 岁 16-6 所 示 ， 点 击 
标记 为 “合并 冲突 ”的 一 行 ， 在 弹出 菜单 中 出 现 A、B、C 三 个 和 这 项 ,分 
别 代表 从 A、B、C 三 个 窗口 复制 相关 内 容 到 当前 位 置 。 


站 JNEADME. txt (Bo 过 | 上] 
ET 精 咸 四) ” 百 录 CD) Same) ee a sr 识 秋 [六 ) pT 
[> A en 


Tac) do0README Dt (B35¢] | . 


图 16-5 kdiff3 神 突 解决 界面 
WEADME, txt (Bosel “> ,JREADOME. tx (Lo > /NEADME txt (Momote 
日 寻 [ 吧 】 妹 动 M) 三 知 DeW 合共) 下 ET 帮助 {MH} 
人 pi 入 溃 色 
Rl COCAEADNE te focal) | © 0cREADME be (Aemotel 
铀 网 。 LTF,B 入 必 风 看 ; pn 
Wser2 hi 有 | 
User2 hacked again 


已 闪 台 ] 


16-6 kdiff3 合并 冲突 行 的 弹出 菜单 


当 通 过 图 16-6 显示 的 弹出 菜单 选择 了 B 和 C 后 ， 可 以 在 图 16-7 中 看 到 在 合并 窗口 中 出 
现 了 标识 B 和 C 的 行 ， 分 人 人 user2 和 | userl np 


a Wx Th ”WTP8 和 
Userl nackad. i Userl nacred 
| wer |1 SR ver) 
WUser2 hacxed 3 User2 hacoed 


User2 hacked agan 4 User? hacked again 


[Ea] Encogng tor seng Codec fom C: UTF-B v 5 尽 风格 ， 


16-7 在 kdiff3 的 冲突 区 域 同时 选取 B 和 C 的 修改 


在 合并 窗口 进行 编辑 ， 将 “Hello，user1l. ”修改 为 “Hello,，userl and user2.”, 
如 图 16-8 所 示 。 修 改 后 ， 可 以 看 到 该 行 的 标识 由 上 改变 为 m， 含 义 是 该 行 是 经 过 手工 修 


改 的 行 。 


图 16-8 在 kdiff3 的 冲突 区 域 编 辑 内 容 


在 合并 窗口 删除 标识 为 从 B 窗口 引入 的 行 “Hello，user2.”， 如 图 16-9 所 示 。 保 存 
退出 即 完成 图 形 化 冲突 解决 。 


图 16-9 完成 kdiff3 圳 突 区 域 的 编辑 


图 形 工具 保存 退出 后 ， 显 示 工 作 区 状态 ,会 看 到 冲突 已 经 解决 。 在 工作 区 还 会 遗留 一 个 
以 OrigQg 结 尾 的 合 并 前 的 多 件 副 本 


S git status 


# On branch maaster 

# Your branch and 'refs/remotes/oriqin/master! have diverged, 
# an Iave | ferey nmi = I, respective 

并 

# Changes to be committed: 

村 

从 modified 9 EADME t 

村 

# Un ked file 

并 (USE " ad file i ide ir hat wi be mmitted 
提 


#doc/VREADME .txt.orig 


查看 暂 存 区 会 发 现 暂 存 区 中 的 冲突 文件 的 三 个 副本 都 已 经 清除 。 


$git ls-files-s 

100644 463dd451d94832f196096bbcoc9cf9f2dof82527 0 doc/README .txt 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 


执行 提交 和 推送 。 


$git commit-m "Say hello to all users." 
[master 7f7bb5e]jSay hello to all users. 
$git push 

Counting objects:14,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(6/6), done. 
Writing objects:100%(8/8),712 bytes, done. 
Total 8(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(8/8),done. 

To file:///path/to/repos/shared.git 
a123390,. .7f7bb5e master->master 


叶 


看 最 近 三 次 的 提交 日 志 ， 会 看 到 最 新 的 提交 是 一 个 合并 提交 。 


$git 1og--oneline--graph-3 
*7f7bb5e Say hello to all users. 
|\ 

|*a123390 Say hello to USser1I， 


*|60b10f3 Say hello to user2. 
| 7/ 


16.5 ”合并 四 : 树 冲突 


如 采 一 个 用 户 将 茶 个 文件 改名 ， 另 外 一 个 用 户 将 同样 的 文件 改 为 
另外 的 名 字 ， 当 这 两 个 用 户 的 提交 进行 合并 操作 时 ，Git 显 然 无 法 蔡 用 
户 做 出 裁决 ， 于 是 束 产 生 了 冲突 。 这 种 因为 文件 名 修改 造成 的 冲突 ， 
称 为 树 冲 突 。 这 种 树 冲突 的 解决 方式 比较 特别 ， 因 此 专题 介绍 


仍旧 使 用 前 面 的 版 本 库 进 行 此 次 实践 。 为 确保 两 个 用 户 的 本 地 版 
本 库 和 共有 至 版 本 库 状 态 一 怪 ， 先 分 别 对 两 个 用 户 的 本 地 版 本 库 执 行 拉 
回 操作 。 


$git pull 


下 面 束 分 别 以 两 个 用 户 的 映 份 执行 提交 ， 将 同样 的 一 个 文件 改 为 
不 同 的 文件 名 ， 制 造 一 个 树 冲突 ， 具 体操 作 过 程 如 下 。 


(1) 用 户 user1 将 文件 docv/README.txt 改 名 为 readme.txt， 提 区 并 
推送 到 共享 版 本 库 。 


$cd/path/to/user1i/workspace/project 

$git mv doc/README.txt readme.txt 

$git commit-m "rename doc/README.txt to readme.txt" 
[master 615c1ff]jrename doc/README.txt to readme ,七 Xt 
1 files changed,0 insertions(+),0 deletions(-) 
rename doc/README.txt=>readme.txt(100%) 

$git push 

Counting objects:3,done. 


Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 
Writing objects:100%(2/2),282 bytes, done. 
Total 2(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(2/2),done. 

To file:///path/to/repos/shared.git 
7f7bb5e. .615c1iff master->master 


(2) 用 户 user2 将 文件 doc/README.txt 改 名 为 README， 并 做 本 
地 提交 。 


$cd/path/to/user2/workspace/project 

$git mv doc/README.txt README 

$git commit-m "rename doc/README.txt to README" 
[master 20180eb]rename doc/README.txt to README 
1 files changed,0 insertions(+),0 deletions(-) 
rename doc/README.txt=> README(100%) 


(3) 用 户 user2 执 行 git pull 操 作 ， 遇 到 合并 冲突 。 


$git pull 

remote:Counting objects:3,done. 

remote:Compressing objects:100%(2/2),done. 

remote:Total 2(delta 0),reused 0(delta 0) 

Unpacking objects:100%(2/2),done. 

From file:///path/to/repos/shared 

7f7bb5e. .615c1iff master->origin/master 

CONFLICT(rename/rename):Rename "doc/README. txt"->"README" in 
branch "HEAD" 

rename "doc/README.txt"->"readme.txt" in 
"615c1iffaa41b2798a56854259caeeb1020c51721" 

Automatic merge failed; fix conflicts and then commit the 
result. 


因为 两 个 用 户 同 时 更 改 了 同一 文件 的 文件 名 并 且 改 成 了 不 同 的 名 
字 ， 于 是 引发 冲突 。 此 时 查看 状态 会 看 到 |: 


$git status 
#0n branch master 


#Your branch and 'refs/remotes/origin/master’' have diverged, 
#and have 1 and 1 different commit(s)each,respectively. 


# 
#Unmerged paths: 


#(USe "git add/rm<file>..." as appropriate to mark resolution) 


## 

#added by US :README 

#both deJleted:doc/VREADME ,七 Xt 
#added by them:readme .txt 

# 


no changes added to commit(use "git add" and/or "git commit-a") 


此 时 查看 一 下 用 户 user2 本 地 版 本 库 的 暂 存 区 ， 可 以 看 到 因为 冲突 
在 编号 为 1、2、3 的 暂 存 区 出 现 了 相同 SHA1 哈 希 值 的 对 象 ， 但 是 文件 


名 各 不 相同 。 


$git ls-files-s 

100644 463dd451d94832f196096bbcOc9cf9f2d0f82527 
100644 463dd451d94832f196096bbcOc9cf9f2d0f82527 
100644 463dd451d94832f196096bbcOc9cf9f2d0f82527 
100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 


OOOPN 


README 
doc/README. txt 
readme .txt 
team/user1.txt 
team/user2.txt 


其 中 在 暂 存 区 1 中 是 改名 之 前 的 dowREADME.txt， 在 暂 存 区 2 中 是 
用 户 user2 改 名 后 的 文件 名 README， 而 暂 存 区 3 是 其 他 用 户 (user1) 


改名 后 的 文件 readme.txt 。 


此 时 的 工作 区 中 存在 两 个 相同 的 文件 README 和 readme.txt 分 别 是 
用 户 user2 和 user1 对 doc/README.txt 重 命名 之 后 的 文件 。 


$1ls-1 readme.txt README 


-rw-r--r--1 jiangxin jiangxin 72 12 月 27 12:25 README 


-rw-r--r--1 jiangxin jiangxin 72 12 月 27 16:53 readme .txt 


16.5.1 手工 操作 解决 树 冲 突 


这 时 user2 应 该 和 user1 商 量 一 下 到 撒 应 该 将 该 文件 改 成 什么 名 字 。 
如 果 双 方 最 终 确 认 应 该 采用 user2 重 命名 的 名 称 ， 则 user2 应 该 进行 下 面 
的 操作 完成 冲突 解决 ， 具 体 探 作 过 程 如 下 。 


(1) 删除 文件 readme.txt 。 


在 执行 git rm 操作 过 程 时 会 弹出 三 条 警告 ， 说 共有 三 个 文件 待 合 
并 。 


$git rm readme.txt 

README :needs merge 
doc/README .txt:needs merge 
readme.txt:needs merge 

rm 'readme.txt' 


(2) 删除 文件 doc/README.txt 。 


执行 删除 过 程 ， 弹 出 的 警告 少 了 一 条 ， 因 为 前 面 的 删除 操作 已 经 
将 一 个 冲突 文件 撤 《出 暂 存 区 了 。 


$git rm doc/README. txt 
README :needs merge 
doc/README .txt:needs merge 
rm 'doc/README .txt'" 


N| 


(3) 添加 文件 README 。 


$git add README 


(4) 这 时 查看 一 下 暂 存 区 ， 会 发 现 所 有 文件 都 在 暂 存 区 0 中 。 


$git ls-files-s 

100644 463dd451d94832f196096bbcoc9cf9f2dof82527 0 README 

100644 430bd4314705257a53241bc1d2cb2cc30f06f5ea 0 team/user1.txt 
100644 a72ca0b4f2b9661d12d2a0c1456649fc074a38e3 0 team/user2.txt 


(5) 提交 完成 冲突 解决 。 


$git commit-m "fixed tree conflict." 
[master e82187e]fixed tree conflict. 


(6) 查看 一 下 最 近 三 次 提交 日 志 ， 看 到 最 新 的 提交 是 一 个 合并 提 


$git log--oneline--graph-3-m--stat 

*e82187e(from 615c1iff)fixed tree conflict. 

人 

| |README | 4++++ 

||readme .txt|14---- 

||2 files changed,4 insertions(+),4 deletions(-) 
|*615c1iff rename doc/README .txt to readme ,七 Xt 

| ldoc/README .txt|4---- 

| | readme ,七 Xt |4++++ 

||2 files changed,4 insertions(+),4 deletions(-) 
*|20180eb rename doc/README.txt to README 

I/ 

|README | 4++++ 

|doc/README. txt|4---- 

|2 files changed,4 insertions(+),4 deletions(-) 


16.5.2 ”交互 式 解 决 树 冲突 


树 冲 突 虽 然 不 能 像 文件 冲突 那样 使 用 图 形 工具 进行 冲突 解决 ， 但 
还 是 可 以 使 用 git mergetool 命 仿 ， 通 过 交互 式 问答 快速 解决 此 类 冲突 。 


目 先 将 user2 的 工作 区 重 置 到 前 一 次 提交 ， 表 执行 git merge 引 发 树 


(1) 重 置 到 前 一 次 提交 。 


$cd/path/to/user2/workspace/project 

$git reset--hard HEADA^ 

HEAD is now at 20180eb rename doc/README.txt to README 
$git clean-fd 


(2) 执行 git merge 引 发 树 冲 突 。 


$git merge refs/remotes/origin/master 

CONFLICT(rename/rename):Rename "doc/README. txt" ->"README" in 
branch "HEAD" 

rename "doc/README.txt" ->"readme.txt" in 
"refs/remotes/origin/master" 

Automatic merge failed; fix conflicts and then commit the 
result. 

$git status-s 

AU README 

DD doc/README. txt 

UA readme ,txXt 


上 面 的 操作 所 引发 的 树 冲 突 ， 可 以 执行 git mergetool 命 令 进行 交互 
式 冲 突 解决 ， 会 如 下 逐一 提示 用 户 进 行 克 择 。 


(1) 执行 git mergetool 命 令 。 忽 上 略 其 中 的 提示 和 警告 。 


$git mergetool 

merge tool candidates:opendiff kdiff3 tkdiff xxdiff meld 
tortoisemerge gvimdiff 
diffuse ecmerge p4merge araxis emerge vimdiff 
Merging: 
doc/README. txt 
README 
readme .txt 
mv :无 法 获取 "doc/README .txt" 的 文件 状态 (stat ) :没有 那个 文件 或 目录 
cp :无 法 获取 "./doc/README ,txt .BACKUP .13869 .txt" 的 文件 状态 (stat ) :没有 
那个 文件 或 目录 
mv :无 法 将 " .merge_file_I3gfzy "移动 
至 ",/doc/README .txt.BASE.13869 .txt" :没有 那个 文件 或 目录 


(2) 询问 对 文件 dowREADME.txt 的 处 理 方式 。 输 入 d 选 择 将 该 文 
件 删除 。 


Deleted merge conflict for "doc/VREADME .txt  : 
{local}:deleted 

{remote}:deleted 

Use(m)odifed or(d)eleted file,or(a)bort?d 


(3) 询问 对 文件 README 的 处 理 方 式 。 输 入 c 选 择 将 该 文件 保留 
(创建 ) 。 


Deleted merge conflict for "README  : 
{local}:created 

{remote}:deleted 

Use(c)reated or(d)eleted file,or(a)bort?c 


(4) 询问 对 文件 readme.txt 的 处 理 方式 。 输 入 d 选 择 将 该 文件 删 


除 。 


Deleted merge conflict for "readme,txt ': 
{local}:deleted 

{remote}:created 

Use(c)reated or(d)eleted file,or(a)bort?d 


啊 
让 
开 
| 


状态 ， 只 有 一 些 尚 未 清理 的 临时 文件 ， 而 冲突 已 经 
解决 。 


$git status-s 
?3 .merge_file I3gfzy 
?3 README .orig 


$git commit-m "fixed tree conflict." 
[master e070bc9]fixed tree conflict. 


(7) 向 共享 服务 器 推送 。 


$git push 

Counting objects:5, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(3/3),done. 
Writing objects:100%(3/3),457 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(3/3),done. 

To file:///path/to/repos/shared.git 
615c1ff. .e070bc9 master->master 


16.6 ”合并 策略 


Git 合 并 操作 文 持 很 多 合并 策略 ， 移 认 会 选择 最 适合 的 合并 党 略 。 
例如 ， 和 一 个 分 文 进 行 合 并 时 会 选择 recursive 合 并 策略 ， 当 和 两 个 或 
两 个 以 上 的 其 他 分 文 进行 合并 时 采用 octopus 合 并 党 略 。 可 以 通过 传递 
参数 使 用 指定 的 合并 策略 ， 命 令 行 如 下 : 


git merge[-s<strategy>][-X<strategy-option>]<commit>... 


其 中 参数 -s 用 于 设 定 合并 策略 ， 参 数 -Xx 用 于 为 所 选 的 合并 策略 提 
供 附加 的 参数 。 
下 面 分 别 介绍 不 同 的 合并 策略 : 
(1) resolve 


该 合并 策略 只 能 用 于 合并 两 个 头 〈“ 即 当前 分 文 和 另外 的 一 个 分 
文 ) ， 使 用 三 向 合并 策略 。 这 个 合并 策略 被 认为 是 最 安全 、 最 快 的 合 
并 策略 。 


(2) recursive 


该 合并 策略 只 能 用 于 合并 两 个 头 〈“ 即 当前 分 文 和 另外 的 一 个 分 
文 ) ， 使 用 三 向 合并 策略 。 这 个 合并 策略 是 合并 两 个 头 指 针 时 的 默认 


n> 


含 并 策略 。 


当 合并 的 头 指 针 拥 有 一 个 以 上 的 祖先 的 时 候 ， 会 针对 多 个 公共 祖 
先 创建 一 个 合并 的 树 ， 并 以 此 作为 三 同 合并 的 参照 。 这 个 合并 筑 略 被 
认为 可 以 实现 冲突 的 最 小 化 ， 而 且 可 以 发 现 和 处 理由 于 重 命名 导致 的 


合并 冲突 。 


这 个 合并 策略 可 以 使 用 下 列 选项 。 


OUurs 


在 遇 到 冲突 的 时 候 ， 选 择 我 们 的 版 本 (当前 分 支 的 版 本 ) ， 而 忽 
略 他 人 的 版 本 。 如 果 他 人 的 改动 和 本 地 改动 不 冲突 ， 会 将 他 人 的 改动 
利 站 几 


不 要 将 此 模式 和 后 面 介绍 的 单纯 的 ours 合 并 策略 相 混 淆 。 后 面 介 
绍 的 ours 合 并 筑 略 直接 丢弃 其 他 分 文 的 变更 ， 无 论 冲 突 与 否 。 


theirs 


和 ours 选 项 相反 ， 直 到 冲突 时 选择 他 人 的 版 本 ， 丢 弃 我 们 的 版 
2 


Subtree[=pathj] 


这 个 选项 使 用 子 树 合并 策略 ， 比 下 面 介绍 的 subtree ( 子 树 合并 ) 
策略 的 定制 能 力 更 强 。 下 面 的 subtree 合 并 策略 要 对 两 个 树 的 目录 移动 
进行 猜测 ， 而 recursive 合 并 策略 可 以 通过 此 参数 直接 对 子 树 目 如 进行 
设置 。 

(3) octopus 

可 以 合并 两 个 以 上 的 头 指针 ， 但 是 拒绝 执行 需要 手动 解决 的 复杂 
合并 。 主 要 的 用 途 是 将 多 个 主题 分 支 合并 到 一 起 。 这 个 合并 宽 略 是 对 
三 个 及 三 个 以 上 的 头 指 针 进 行 合并 时 的 默认 合并 策略 。 


(4) ours 


可 以 合并 任意 数量 的 头 指针 ， 但 是 合并 的 结果 总 是 使 用 当前 分 支 
的 内 容 ， 委 弃 其 他 分 支 的 内 容 。 


(5) subtree 


这 是 一 个 经 过 调整 的 recursive 策 略 。 当 合并 树 A 和 BH 时 ， 如 果 B 和 A 
的 一 个 子 树 相同 ，B 首 先进 行 调整 以 匹配 A 的 树 的 结构 ， 以 免 两 棵 树 在 
同一 级 别 进行 合并 。 同 时 也 针对 两 棵 树 的 共同 祖先 进行 调整 。 


关于 子 树 合并 会 在 第 4 篇 的 第 24 章 * 子 树 合并 ”中 详细 介绍 。 


16.7 “合并 相关 的 设置 


可 以 通过 git config 命 令 设置 与 合并 相关 的 配置 变量 ， 对 合并 进行 
配置 。 下 面 生 一 些 音 用 的 设置 。 


(1) merge.conflictstyle 


该 配置 变量 定义 冲突 文件 中 冲突 的 标记 风格 ， 有 两 个 可 用 的 风 
格 ， 默 认 的 "merge" 或 "diff3"。 


默认 的 "merge" 风 格 使 用 标准 的 冲突 分 界 符 (<<<<<<< 
=======> > > > > > > ) 对 冲突 内 容 进 行 标识 ， 其 中 的 两 个 文字 块 
分 别 是 本 地 的 修改 和 他 人 的 修改 。 


如 果 使 用 "diff3" 风 格 ， 则 会 在 冲突 中 出 现 三 个 文字 块 ， 分 别 是 


< <<<<< 和 和 | 川 之 间 的 本 地 更 改版 本 、 必 和 ======= 之 间 的 原 
始 (共同 祖先 ) 版 本 和 ======= 和 > > > > > > > 之 间 的 他 人 更 改 的 
版 本 。 例 如 : 


User1 hacked. 

<<<<<<<HEAD 

Hello, user2. 

[|||||ll|lmerged common ancestors 
Hello. 


Hello, user1. 
>>>>>>>a1l23390b8936882bd53033a582ab540850b6b5fb 


User2 hacked. 
User2 hacked again， 


(2) merge.tool 


设 定 执行 git mergetool 进 行 冲突 解 决 时 调用 的 图 形 化 工具 。 配 置 变 
量 merge.tool 可 以 设置 为 如 下 内 置 支持 的 工 
有 具 : "kdiff3" 、"tkdiff"、"meld" 、"xxdiff"、"emerge" 、"vimdiff"、"gvim 
diff" ~ "diffuse" ~ "ecmerge" 、 "tortoisemerge" 、"p4merge" 、"araxis" 相 "0o 


pendiff" ° 


$git config--global merge.tool kdiff3 


如 果 将 merge.tool 设 置 为 其 他 值 ， 则 使 用 上 自 定 义工 具 进 行 冲 突 解 
决 。 目 定义 工具 需要 通过 mergetool.<tool> .cmd 对 上 自 定 义工 具 的 命令 


行进 行 设置 。 
(3) mergetool.<tool> .path 


如 采 git mergetool 文 持 的 冲突 解决 工具 安装 在 特殊 位 置 ， 可 以 使 用 
mergetool.<tool> .path 对 工具 <tool> 的 安 效 位 置 进行 设置 。 例 如 : 


$git config--global mergetool.kdiff3.path/path/to/kdiff3 


(4) mergetool.<tool> .cmd 


如 有 果 所 用 的 冲突 解决 工具 不 在 内 置 的 工具 列表 中 ， 还 可 以 使 用 
mergetool.<tool> .cmd 对 目 定 义工 具 的 命令 行进 行 设置 ， 同 时 要 将 
merge.tool 设 置 为 <tool>。 


目 定 义工 具 的 命令 行 可 以 使 用 Shell 变 量 。 例 如 : 


$git config--global merge.tool mykdiff3 


$git config--global mergetool.mykdiff3.cmd '/usr/bin/kdiff3 


-L1 "$MERGED(Base)" -L2 "$MERGED(Local)" -L3 "$MERGED(Remote)" 
--auto-0 "$MERGED" "$BASE™" "$LOCAL™ "$REMOTE™'" 


(5) merge.log 


征 否 在 合并 提交 


false。 


的 提交 说 明 中 包含 合并 提交 的 概要 信息 。 瞪 认为 


吾 ， 


第 17 章 ”Git 里 程 碑 


里 程 碑 即 Tag， 征 人 为 对 提交 进行 的 命名 。 这 和 Git 的 提交 ID 是 否 
太 长 无 关 ， 使 用 任何 数字 版 本 号 无 论 长 短 ， 都 没有 使 用 一 个 直观 的 表 
意 的 字符 串 来 得 方便 。 例 如 : 用 里 程 碑 名 称 "v2.1" 对 应 于 软件 的 2.1 发 
布 版 本 正比 使 用 提交 ID 要 直观 得 多 。 


对 于 里 程 碑 ， 实 际 上 我 们 并 不 卫生 ， 在 第 2 篇 的 “第 10 革 Git 基 本 操 
作 ” 中 ， 就 介绍 了 使 用 里 程 碑 来 对 工作 进度 “留影 纪念， 并 使 用 git 
describe 命 令 显 示 里 程 碑 和 提交 ID 的 组 合 来 代表 软件 的 版 本 号 。 本 章 将 
详细 介绍 里 程 碑 的 创建 、 删 除 和 共享 ， 还 会 介绍 里 程 碑 存在 的 三 种 不 
同形 式 : 轻 量 级 里 程 碑 、 读 注释 的 里 程 碑 和 市 签名 的 里 程 碑 。 


接 下 来 的 三 章 ， 将 对 一 个 名 为 "Hello World" 的 示例 版 本 库 进 行 研 
究 ， 这 个 版 本 库 不 需要 我 们 从 头 建 立 ， 可 以 直接 从 Github 1 上 克隆 。 
先 使 用 下 面 的 方法 在 本 地 创建 一 个 镜像 ， 用 作 本 地 用 户 的 共享 版 本 
库 。 


进入 本 地 版 本 库 根 目录 下 。 


$mkdir-p/path/to/repos/ 
$cd/path/to/repos/ 


从 Github 上 镜像 hello-world.git 版 本 库 。 


如 果 Git 是 1.6.0 或 更 新 的 有 版本， 可 以 使 用 下 面 的 命令 建立 版 本 库 镜 
人 


$git clone--mirror git://github.com/ossxp-com/hello-world.git 


否则 使 用 下 面 的 命令 建立 版 本 库 镜 像 。 


$git clone--bare\ 
git://github.com/ossxp-com/hello-world.git hello-world.git 


完成 上 面 的 操作 后 ， 就 在 本 地 建立 了 一 个 课 版 本 
库 /path/to/repos/hello-world.git。 接 下 来 用 户 user1 和 user2 分 别 在 各 自 的 
工作 区 克隆 这 个 裸 版 本 库 。 使 用 如 下 命令 即 可 : 


$git clone file:///path/to/repos/hello-world.git\ 
/path/to/user1i/workspace/hello-world 

$git clone file:///path/to/repos/hello-world.git\ 
/path/to/user2/workspace/hello-world 
$git--git-dir=/path/to/user1i/workspace/hello-world/ .git\ 
config user.name user1 
$git--git-dir=/path/to/user1i/workspace/hello-world/ .git\ 
config user.email useriQ@sun.ossxp.com 
$git--git-dir=/path/to/user2/workspace/hello-world/ .git\ 
config user.name user2 
$git--git-dir=/path/to/user2/workspace/hello-world/ .git\ 
config user.email user2@moon.ossxp.com 


17.1 显示 里 程 碑 


里 程 碑 可 以 使 用 git tag 命 
出 中 出 现 ， 下 面 分 


1. 命 


不 市 任何 参数 执行 git tag 命 


表 。 


令 gittag 


别 对 这 上 


些 命 


令 来 显示 ， 里 程 碑 还 可 以 在 其 他 命令 的 输 


令 加 以 介绍 。 


令 ， 即 可 显示 当前 版 本 库 的 里 程 碑 列 


$cd/path/to/user1i/workspace/hello-world 
$git tag 


jx/v1. 
jx/v1. 
jx/v1. 
jx/v1. 
jx/v1. 
jx/Vv2. 
jx/Vv2. 
JjX/V2 ， 
JjX/V2 ， 


0 
0 
工 


记忆 和 


-i18n 


里 程 碑 创建 的 时 候 可 能 包 


显示 说 明 ， 使 用 -n<num> 参数 ， 显 示 最 多 <num> 行 里 程 碑 的 说 明 。 


$git tag-ni 

jxX/v1.0 Version 1.0 
jx/v1.0-i1i8n ii8n support 
jxX/v1.1 Version 1.1 
jxX/Vv1.2 Version 1.2:allow 
jxX/v1.3 Version 1.3:Hello 
jxX/Vv2.0 Version 2.0 
JX/v2.1 Version 2.1:fixed 
jxX/v2.2 Version 2.2:allow 
jxX/Vv2.3 Version 2.3:Hello 


一 个 说 明 。 在 显示 里 程 碑 的 时 候 同 时 


for v1i.0 


spaces in username. 
world speaks in Chinese now. 


typo. 
Spaces in username. 
world speaks in Chinese now. 


还 可 以 使 用 通配符 对 输出 进行 过 滤 。 只 显示 名 称 和 通配符 相符 的 
里 程 碑 。 


$git tag- 工 jx/v2* 


在 查看 日 志 时 使 用 参数 --decorate 可 以 看 到 提交 对 应 的 里 程 碑 及 其 
他 引用 。 


$git log--oneline--decorate 

3e6070e(HEAD, tag:jx/v1.0,origin/master,origin/HEAD,master )Show 
version. 

75346b3 Hello world initialized. 


3. 命 令 git describe 


使 用 命令 git describe 将 提交 显示 为 一 个 易 记 的 名 称 。 这 个 易 记 的 
名 称 来 自 于 建立 在 该 提交 上 的 里 程 碑 ， 若 该 提交 没有 里 程 碑 则 使 用 该 
是 区 历史 版 本 上 的 里 程 碑 并 加 上 可 理解 的 寻 址 信息 。 


如 有 果 该 提交 恰好 被 打上 一 个 里 程 碑 ， 则 显示 该 里 程 碑 的 名 子 。 


$git describe 

jx/v1.0 

$git describe 384f1e0 
jxX/Vv2.2 


大 提交 没有 对 应 的 里 程 碑 ， 但 是 在 其 祖先 版 本 上 建 有 里 程 碑 ， 则 
使 用 类 似 <tag>-<num>-g<commit> 的 格式 显示 。 


其 中 <tag> 是 最 接近 的 祖先 提交 的 里 程 碑 名 字 ，<num> 是 该 里 
程 牧 和 提交 之 间 的 距离 ，<commit> 是 该 提交 的 精简 提交 ID 。 


$git describe 610e78fc95bf2324dc5595fa684e08e1089f5757 
jx/v2.2-1-g610e78f 


如 打工 作 区 对 文件 有 修改 ， 还 可 以 通过 后 组 -dirty 表 示 出 来 。 


$echo hacked> >README;git describe--dirty; git checkout- -README 
jxX/v1.0-dirty 


如 果 提 交 本 身 没有 包含 里 程 碑 ， 可 以 通过 传递 --always 参 数 显示 精 
位 提交 1D， 否则 会 出 错 。 


$git describe master^--always 
75346b3 


命令 git describe 十 非 党 有 用 的 命令 ， 可 以 将 该 命令 的 输出 用 作 软 
件 的 版 本 号 。 


在 此 之 前 曾经 演示 过 这 个 应 用 ， 马 上 还 会 看 到 。 


4. 命 令 git name-rev 


命令 git name-rev 和 git describe 类 似 ， 会 显示 提交 ID 及 其 对 应 的 一 
个 引用 。 罗 认 优 和 使 用 分 文 名 ， 除 非 使 用 --tags 参 数 。 还 有 一 个 显著 的 
不 同 束 是 ， 如 采 提 交 上 没有 相对 应 的 引用 ， 则 会 使 用 最 狐 提 交 上 的 引 
用 名 称 并 加 上 疝 后 回溯 的 符号 于 <num>>。 


默认 优先 显示 分 文 名 。 


$git name-rev HEAD 
HEAD master 


使 用 --tags 优 先 使 用 里 程 碑 。 


之 所 以 在 对 应 的 里 程 碑 引 用 名 称 后 面 加 上 后 缀 0， 是 因为 该 引用 
指向 的 是 一 个 tag 对 象 而 非 提交 。 用 ^0 后 缀 指向 对 应 的 提交 。 


$git name-rev HEAD--tags 
HEAD tags/jx/v1.0O^0O 


如 果 提 交 上 没有 对 应 的 引用 名 称 ， 则 会 使 用 新 提交 上 的 引用 名 称 


并 加 上 后 级 一 <num>>。 后 级 的 含义 是 第 <num> 个 祖先 提交 。 


$git name-rev--tags 610e78fc95bf2324dc5595fa684e08e1089f5757 
610e78fc95bf2324dc5595fa684e08e1089f5757 tags/jx/v2.3~1 


命令 git name-rev 可 以 对 标准 输入 中 的 提交 ID 进 行 改写 ， 使 用 管道 


符号 对 前 一 个 命令 的 输出 进行 改写 ， 会 显示 神奇 的 效果 。 


$git log--pretty=oneline origin/helper/master|\ 
git name-rev--tags--stdin 


bb4fef88fee435bfac04b8389cf193d9c04105a6( tags/jx/v2. 


e for Chinese. 


610e78fc95bf2324dc5595fa684e08e1089f5757(tags/jx/v2. 


I18N support. 


384f1ie0d5106c9c6033311a608b91c69332fe0a8(tags/jx/v2. 


llow spaces in username. 


eS5e62107f8f8d0a5358c3aff993cf874935bb7fb(tags/jx/v2. 


typo:-help to--help 


5d7657b2f1ia8e595c01c812dd5b2f67ea133f456(tags/jx/v2. 


arguments using getopt_long. 


3e6070eb2062746861b20e1ie6235fed6f6d15609(tags/jx/v1. 


version. 


75346b3283da5d8117f3fe66815f8aaaf5387321(tags/jx/v1. 


world initialized. 


[1| https://github.com/ossxp-com/hello-world/ 


3^0)Translat 
3~1)Add 
2^0)Bugfix:a 
1^0)fixed 
0A^A0)Parse 
09A^A0 )Show 


0~1)Hello 


17.2 ”创建 里 程 碑 


创建 里 程 碑 依 然 是 使 用 git tag 命 令 。 创 建 里 程 碑 的 用 法 有 以 下 几 
种 : 


法 1:git tag<tagname>[<commit>] 

法 2:git tag-a<tagname>[<commit>] 

法 3:git tag-m<msg><tagname>[<commit>] 
用 法 4:git tag-s<tagname>[<commit>] 

法 5:git tag-u<key-id><tagname>[<commit>] 


其 中 : 


用 法 1 是 创建 轻 量 级 里 程 碑 。 


用 法 2 和 用 法 3 相同 ， 都 是 创建 带 说 明 的 里 程 碑 。 其 中 用 法 3 直接 通 
过 -m 参 数 提供 里 程 碑 创 建 说 明 。 


用 法 4 和 用 法 5 相同 ， 都 是 创建 带 GnuPG 签 名 的 里 程 碑 。 其 中 用 法 5 
用 -u 参 数 选 择 指定 的 私 钥 进 行 签名 。 


创建 里 程 碑 需要 输入 里 程 碑 的 名 字 (<tagname > ) 和 一 个 可 选 的 


提交 ID (<commit>) 


如 条 没有 提供 提交 ID， 则 基于 头 指针 HEAD 创 建 里 程 碑 。 


17.2.1 轻 量 级 里 程 碑 


轻 量 级 里 程 牧 最 简单 ， 创 建 时 无 须 输入 描述 信息 。 我 们 来 看 看 如 
何 创建 轻 量 级 里 程 碑 : 


(1) 先 创建 一 个 空 提交 


$git commit--allow-empty-m "blank commit." 
[master 60a2f4f]blank commit. 


(2) 在 刚刚 创建 的 空 提交 上 创建 一 个 轻 量 级 里 程 碑 ， 名 为 


mytag ° 


省 略 了 < commit> 参数 ， 相 当 于 在 HEAD 上 即 最 新 的 空 提交 上 创 
建 里 程 碑 。 


$git tag mytag 


(3) 查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 


$git tag-l1 my* 
mytag 


1. 轻 量 级 里 程 碑 的 奥秘 


当 创建 了 里 程 碑 mytag 后 ， 会 在 版 本 库 的 .git/refs/tags 目 孙 下 创建 一 
个 新 文件 。 


查看 一 下 这 个 引用 文件 的 内 容 ， 会 发 现 是 一 个 40 位 的 SHA1 哈 希 
值 。 


$cat .git/refs/tags/mytadg 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb 


用 git cat-file 命 令 检查 轻 量 级 里 程 碑 指向 的 对 象 。 轻 量 级 里 程 碑 实 
际 上 指向 的 是 一 个 提交 。 


$git cat-file-t mytag 
commit 


查看 该 提交 的 内 容 ， 发 现 束 古 刚 刚 进行 的 空 提交 。 


$git cat-file-p mytag 

tree 1d902fedc4eb732f17e50f111dcecb638f10313e 

parent 3e6070eb2062746861b20e1e6235fed6f6d15609 
author User1<uUser1Q@sun.ossxp.com>1293790794+0800 
committer useri<user1iQ@sun.ossxp.com>1293790794+0800 
blank commit. 


2. 轻 量 级 里 程 碑 的 缺点 


轻 量 级 里 程 碑 的 创建 过 程 没有 记录 ， 因 此 无 法 知道 古 谁 创建 的 里 
程 碑 ， 何 时 创建 的 里 程 碑 。 在 团队 协同 开发 时 ， 尽 量 不 要 采用 此 种 偷 
懒 的 方式 创建 里 程 碑 ， 而 是 采用 后 两 种 方式 。 


还 有 git describe 命 令 默 认 不 使 用 轻 量 级 里 程 碑 生成 版 本 摘 述 字符 


执行 git describe 命 令 ， 发 现 生 成 的 版 本 描述 字符 串 ， 使 用 的 是 前 
一 个 版 本 上 的 里 程 碑 名 称 。 


$git describe 
jx/v1.0-1-g60a2f4f 


使 用 --tags 参 数 ， 也 可 以 将 轻 量 级 里 程 碑 用 作 版 本 描述 从 


$git describe--tags 
mytag 


17.2.2 ”和 带 说 明 的 里 程 碑 


带 说 明 的 里 程 碑 ， 就 是 使 用 参数 -a 或 -m <msg> 调 用 git tag 命 令 ， 
在 创建 里 程 碑 的 时 候 提 供 一 个 天 于 该 里 程 碑 的 说 明 。 下 面 来 看 看 如 何 
创建 市 说 明 的 里 程 碑 : 


(1) 还 是 先 创建 一 个 空 提交 


$git commit--allow-empty-m "blank commit for annotated tag 
test." 
[master 8a9f3dilblank commit for annotated tag test. 


(2) 在 刚刚 创建 的 空 提交 上 创建 一 个 带 说 明 的 里 程 碑 ， 名 为 


mytag2 ° 


下 面 的 命令 使 用 了 -m<msg> 参数 ， 在 命令 行 给 出 了 新 建 里 程 碑 
的 说 明 。 


$git tag-m "My frst annotated tag." mytag2 
(3) 查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 


$git tag-1 my*-ni 
mytag blank commit. 
mytag2 My first annotated tag. 


下 面 来 看 看 市 说 明 里 程 碑 的 奥秘 。 当 创建 了 带 说 明 的 里 程 碑 
mytag2 后 ， 会 在 版 本 库 的 .git/refs/tags 目 录 下 创建 一 个 新 的 引用 文件 。 


查看 一 下 这 个 引用 文件 的 内 容 : 


$cat .git/refs/tags/mytag2 
149b6344e8ofc190bda5621cd71df391d3dd465e 


用 git catrfile 命 令 检查 该 里 程 碑 (市 说 明 的 里 程 碑 ， 指向 的 对 象 ， 
会 发 现 指 癌 的 不 再 是 一 个 提交 ， 而 是 一 个 tag 对 象 。 


$git cat-file-t mytag2 
tag 


查看 该 提交 的 内 容 ， 会 发 现 mytag2 对 象 的 内 容 不 是 之 前 我 们 熟悉 
的 提交 对 象 的 内 容 ， 而 是 包含 了 创建 里 程 碑 时 的 说 明 ， 以 及 对 应 的 提 


交 ID 等 信息 。 


$git cat-file-p mytag2 

object 8a9f3d16ce2b4d39b5d694de10311207f289153f 

type commit 

tag mytag2 

tagger user1i<user1iQ@sun.ossxp.com>Sun Jan 2 14:10:07 2011+0800 
My first annotated tag. 


由 此 可 见 使 用 带 说 明 的 里 程 碑 ， 会 在 版 本 库 中 建立 一 个 新 的 对 象 
ttag 对 象 ) ， 这 个 对 象 会 记录 创建 里 程 牧 的 用 户 (tagger) ， 创 建 里 


程 碑 的 时 间 ， 以 及 为 什么 要 创建 里 程 碑 。 这 束 避 免 了 轻 量 级 里 程 碑 因 
为 匿名 创建 而 无 法 追 踩 的 缺点 。 


融 说 明 的 里 程 碑 是 一 个 tag 对 象 ， 在 版 本 库 中 以 一 个 对 象 的 方式 存 
在 ， 并 用 一 个 40 位 的 SHA1 哈 希 值 来 表示 。 这 个 哈 希 值 的 生成 方法 和 前 
面 介 绍 的 commit 对 象 、tree 对 象 、blob 对 和 象 一 样 。 至 此 ，Git 对 和 象 库 的 
四 类 对 象 我 们 残 都 已 经 研究 到 了 。 
Sgit cat-file tag mytag2|wc-c 


$(printf "tag 148\000";git cat-file tag mytag2)|shaisum 
149b6344e80fc1i90bda5621cd71df391d3dd465e- 


里 然 mytag2 本 号 是 一 个 tag 对 象 ， 但 在 很 多 Git 命 令 中 ， 可 以 直接 将 
其 视 为 一 个 提交 。 下 面 的 git log 命 令 ， 显 示 mytag2 指 癌 的 提交 日 志 。 


$git log-1--pretty=oneline mytag2 
8a9f3d16ce2b4d39b5d694de10311207f289153f blank commit for 
annotated tag test. 


有 了 时， 需要 得 到 里 程 碑 指 向 的 提交 对 象 的 SHA1 哈 希 值 。 


直接 用 git rev-parse 命 令 查看 mytag2 得 到 的 是 tag 对 象 的 ID ， 并 非 提 
交 对 象 的 ID。 


$git rev-parse mytag2 
149b6344e8ofc190bda5621cd71df391d3dd465e 


使 用 下 面 几 种 不 同 的 表示 法 ， 则 可 以 获得 mytag2 对 象 所 指向 的 提 
区 对 象 的 ID。 


$git rev-parse mytag2^{commit} 
8a9f3d1i6ce2b4d39b5d694de10311207f289153f 
$git rev-parse mytag2 人 ^{} 
8a9f3d1i6ce2b4d39b5d694de10311207f289153f 
$git rev-parse mytag2^0 
8a9f3d1i6ce2b4d39b5d694de10311207f289153f 
$git rev-parse mytag2~0 
8a9f3d1i6ce2b4d39b5d694de10311207f289153f 


17.2.3” 带 签 名 的 里 程 碑 


市 签名 的 里 程 碑 和 上 面 介 绍 的 市 说 明 的 里 程 碑 本 质 上 十 一 样 的 ， 
都 古 在 创建 里 程 碑 的 时 候 在 Git 对 象 库 中 生成 一 个 tag 对 象 ， 只 不 过 带 签 
名 的 里 程 碑 多 做 了 一 个 工作 :为 里 程 碑 对 象 添 加 GnuPG 人 签名 。 


创建 带 签 名 的 里 程 碑 也 非常 集 单 ， 使 用 参数 -s 或 -u < key-id> 即 
可 。 还 可 以 使 用 -m<msg> 参数 直接 在 命令 行 中 提供 里 程 碑 的 描述 。 
创建 带 签 名 的 里 程 碑 的 一 个 前 提 是 需要 安装 GnuPG， 并 且 建 立 相 应 的 
公 钥 / 私 钥 对 。 


GnuPG 可 以 在 各 个 平台 上 安装 。 

在 Linux 如 Debian/Ubuntu 上 安装 ， 执 行 : 
$sudo aptitude install gnupg 

在 Mac OS X 上 可 以 通过 Homebrew 安 装 : 
$brew install gnupg 

在 Windows 上 可 以 通过 cygwin 安 装 gnupg。 


为 了 演示 创建 市 签名 的 里 程 碑 ， 还 是 事先 创建 一 个 空 提交 : 


$git commit--allow-empty-m "blank commit for GnuPG-signed tag 
test." [master ebcf6d6]blank commit for GnuPG-signed tag test. 


直接 在 刚刚 创建 的 空 提交 上 创建 一 个 带 签 名 的 里 程 碑 mytag3 很 可 
能 会 失败 : 


$git tag-s-m "My frst GPG-signed tag." mytag3 
gpg:"user1i<user1i@sun.ossxp.com> "已 跳 过 : 私 钥 不 可 用 
gpg:signing failed: 私 钥 不 可 用 
error:gpg failed to sign the tag 
error:unable to sign the tag 


之 所 以 等 名 失败 ， 征 因为 找 不 到 签名 可 用 的 公 钥 / 私 钥 对 。 使 用 下 
面 的 命令 可 以 碍 看 当前 可 用 的 GnuPG 公 钥 。 


$gpg--list-keys 

/home/jiangxin/ .gnupg/pubring.gpg 

pub 1024D/FBC49D091 2006-12-21[ 有 效 至 :2016-12-18] 
uid Jiang Xin<worldhello.net@gmail.com> 

uid Jiang Xin<jiangxin@ossxp.com> 

sub 2048g/448713EB 2006-12-21[ 有 效 至 :2016-12-18] 


可 以 看 到 GnuPG 的 公 钥 链 (pubring) 中 只 包含 了 Jiang Xin 用 户 的 
公 钥 ， 疝 没有 uesr1 用 户 的 公 钥 。 


实际 上 在 创建 带 签 名 的 里 程 碑 时 ， 并 非 一 定 要 使 用 签名 者 本 人 的 
公 钥 / 私 钥 对 进行 签名 ， 使 用 -u<key-id> 参数 调用 就 可 以 用 指定 的 公 
钥 / 私 钥 对 进行 签名 ， 对 于 此 例 可 以 使 用 FBC49D01 作 为 <key-id>。 但 
如 果 没 有 可 用 的 公 钥 / 私 钥 对 ， 或 者 硕 望 使 用 提交 者 本 人 的 公 钥 / 私 钥 


对 进行 签名 ， 束 需要 为 提交 者 : user1<user1@sun.ossxp.com> 创 建 对 
应 的 公 钥 / 私 钥 对 。 


使 用 命令 gpg--gen-key 来 创建 公 钥 / 私 钥 对 。 


$gpg--gen-key 


按照 提示 一 步 一 步 操作 即 可 。 需 要 注意 的 有 : 


在 创建 公 钥 / 私 钥 对 时 ， 会 提示 输入 用 户 名 ， 输 入 User1， 提 示 输 
入 邮件 地 址 ， 输 入 userl1@sun.ossxp.com， 其 他 可 以 采用 默认 值 。 


在 提示 输入 密码 时 ， 为 了 简单 起 见 可 以 直接 按 下 回 车 ， 即 使 用 至 


站 令 。 


在 生成 公 钥 / 私 钥 对 过 程 中 ， 会 提示 用 户 做 一 些 随 机 操作 以 便 产 生 
更 好 的 随机 数 ， 这 时 不 集 的 晃动 鼠标 束 可 以 了 。 


$gpg--list-keys 
/home/jiangxin/ .gnupg/pubring.gpg 


pub 1024D/FBC49DO1 2006-12-21[ 有 效 至 :2016-12-18] 
uid Jiang Xin<worldhello.net@gmail.com> 

uid Jiang Xin<jiangxin@ossxp.com> 

sub 2048g/448713EB 2006-12-21[ 有 效 至 :2016-12-18] 
pub 2048R/37379C67 2011-01-02 

uid User1<user1@sun,ossxp,com>> 

sub 2048R/2FCFB3E2 2011-01-02 


很 显然 用 户 userl 的 公 钥 / 私 钥 对 已 经 建立 。 现 在 吏 可 以 直接 使 用 -s 
参数 来 创建 市 签名 的 里 程 碑 了 。 


$git tag-s-m "My frst GPG-signed tag." mytag3 


查看 里 程 碑 ， 可 以 看 到 该 里 程 碑 已 经 创建 。 


$git tag-1 my*-n1i 

mytag blank commit. 

mytag2 My first annotated tag. 
mytag3 My first GPG-signed tag. 


和 带 说 明 的 里 程 碑 一 样 ， 在 Git 对 象 库 中 也 建立 了 一 个 tag 对 象 。 查 
看 该 tag 对 象 可 以 看 到 其 中 包含 了 GnuPG 签 名 。 


$git cat-file tag mytag3 

object ebcf6d6b06545331df156687ca2940800a3c599d 

type commit 

tag mytag3 

tagger user1i<user1iQ@sun.ossxp.com>1293960936+0800 

My first GPG-signed tag. 

----- BEGIN PGP SIGNATURE----- 

Version:GnuPG v1.4.10(GNU/Linux) 
iQECBAABAgAGBQJNIEbOoOAAoOJEO9W1fg3N5xn42gH/jFDEKobqlupNKFvmkI1t9d6 
lApDFUdcFMPWvxo/eq8VjcQyRcb1X1bGJj+pxXk455fDL1iNWonaJa6HE6RLU868x 
CQIWqwelkCelfmOS5GE9FnPd2SmJsiDkTPZZzINyalHylF5ZbrExH506JyCFk//FC2 
8zRApSbrsj3yAWMStwWOfGqHKLuYq+sdepzGnnFnhhzkJhusMHUkTIfpLwaprhMsm 
1IIxXKNm9i0Zf/tzq4a/RON8NiFH1/9M95iV200I9PUuURWedVOtEPS60nax2yT3JE 
I/w9gtIiBOeb5uAz2Xrt5AUwt9JJTkSmmv2HBqWwCq5wefxs/ub26iPmef35PwAgA= 
=jdrN 


要 入 证 签名 的 有 效 性 ， 如 采 直 接 使 用 gpg 命 令 会 比较 麻烦 ， 因 为 需 
要 将 这 个 文件 拆 分 为 两 个 ， 一 个 是 不 包含 签名 的 里 程 碑 内 容 ， 男 外 一 


个 是 签名 本 号 。 还 好 可 以 使 用 命令 git tag-v 来 验证 里 程 碑 签名 的 有 效 


$git tag-v mytag3 

object ebcf6d6b06545331df156687ca2940800a3c599d 
type commit 

tag mytag3 

tagger user1i<user1iQ@sun.ossxp.com>1293960936+0800 
My first GPG-signed tag. 


gpg: 于 2011 年 01 月 02 日 星期 日 17 时 35 分 36 秒 CST 创 建 的 签名 ,使 用 RSA, 钥 
37379C67 


鲜 
< 


0 


b 


17.3 删除 里 程 碑 


如 采 里 程 碑 建立 在 了 错误 的 提交 上 ， 或 者 对 里 程 碑 的 命名 不 满 
意 ， 可 以 删除 里 程 碑 。 删 除 里 程 碑 使 用 命令 git tag-d， 下 面 用 命令 删除 
里 程 碑 mytag 。 
$git tag-d mytag 
Deleted tag 'mytag' (was 60a2f4f) 
里 程 碑 没 有 类 似 reflog 的 变更 记录 机 制 ， 一 旦 删除 不 易 恢复 ， 慎 
用 。 在 删除 里 程 碑 mytag 的 命令 输出 中 ， 会 显示 该 里 程 碑 所 对 应 的 提交 
ID,， 一 旦 发 现 删 除 错误 ， 赶 紧 补救 还 来 得 及 。 下 面 的 命令 实现 对 里 程 
人 碑 mytag 的 重建 。 


$git tag mytag 60a2f4f 


Git 没 有 提供 对 里 程 碑 重 命名 的 命令 ， 如 果 对 里 程 碑 名 字 不 满意 的 
话 ， 可 以 删除 旧 的 里 程 碑 ， 然 后 重新 用 新 的 名 称 创建 里 程 碑 。 


为 什么 没有 提供 重 命名 里 程 碑 的 命令 呢 ? 按理 说 只 
将 .givrefs/tags/ 下 的 引用 文件 改名 就 可 以 了 。 这 是 因为 里 程 碑 的 名 字 不 
但 反映 在 .gitrefs/tags 引 用 目录 下 的 文件 名 ， 而 且 对 于 市 说 明 或 签名 的 
里 程 碑 ， 里 程 碑 的 名 字 还 反映 在 tag 对 象 的 内 容 中 。 尤 其 是 带 签 名 的 里 


程 碑 ， 如 采 修 改 里 程 碑 的 名 字 ， 不 但 里 程 碑 对 象 内 容 势 必要 变化 ， 而 
且 里 程 碑 也 要 重新 进行 签名 ， 这 显然 难以 目 动 实现 。 


在 第 6 篇 第 35 章 的 “35.4 ”Git 版 本 库 整 理 ” 一 市 中 会 介绍 使 用 git 
filter-branch 命 令 实现 对 里 程 夏目 动 重 命名 的 方法 ， 但 是 那个 方法 也 不 
能 受 发 无 损 地 实现 对 签名 里 程 碑 的 重 命名 ， 被 重 命名 的 签名 里 程 碑 中 
的 签名 会 被 去 除 ， 从 而 成 为 带 说 明 的 里 程 碑 。 


17.4 不 要 随意 更 改 里 程 碑 


里 程 碑 建立 后 ， 如 采 需 要 修改 ， 可 以 使 用 同样 的 里 程 碑 名 称 重 新 
建立 ， 不 过 需要 加 上 -f 蕊 -force 参 数 强制 覆 次 已 有 的 里 程 碑 。 


更 改 里 程 碑 要 慎重 ， 一 个 原因 古里 程 碑 从 概念 上 讲 是 对 历史 提交 
的 一 个 标记 ， 不 应 该 随意 变动 。 另 外 一 个 原因 是 里 程 碑 一 旦 被 他 人 同 
步 ， 如 果 修 改 里 程 碑 ， 已 经 同步 该 里 程 碑 的 用 户 并 不 会 目 动 更 新 ， 这 
束 导 致 一 个 相同 名 称 的 里 程 碑 在 不 同 用 户 的 版 本 库 中 的 指向 不 同 。 下 
面 束 看 看 如 何 与 他 人 共 至 里 程 碑 。 


17.5 “共享 里 程 碑 


现在 看 看 用 户 user1 的 工作 区 状态 。 可 以 看 出 现在 的 工作 区 相 比 上 
游 有 三 个 新 的 提交 。 


$git status 

#0n branch master 

#Your branch is ahead of 'origin/master' by 3 commits. 
# 

nothing to commit(working directory clean) 


那么 如 有 果 执 行 git push 命 令 同 上 游 推 送 ， 会 将 本 地 创建 的 三 个 里 程 
人 碑 推 送 到 上 游 吗 ? 通过 下 面 的 操作 来 试 一 试 。 


癌 上 游 推 运 。 


$git push 

Counting objects:3,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(3/3),done. 
Writing objects:100%(3/3),512 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(3/3),done. 

To file:///path/to/repos/hello-world.git 
3e6070e..ebcf6d6 master->master 


通过 执行 git ls-remote 可 以 查看 上 游 版 本 库 的 引用 ， 会 发 现 本 地 建 
立 的 三 个 里 程 碑 ， 并 没有 推送 到 上 游 。 


$git ls-remote origin my* 


创建 的 里 程 碑 ， 默 认 只 在 本 地 版 本 库 中 可 见 ， 不 会 因为 对 分 文 执 
行 推送 而 将 里 程 碑 也 推送 到 远程 版 本 库 。 这 样 的 设计 显然 更 为 合理 ， 
否则 的 话 ， 每 个 用 户 本 地 创建 的 里 程 碑 都 目 动 癌 上 游 推 送 ， 那 么 上 游 
的 里 程 碑 将 有 多 么 杂乱 ， 而 且 不 同 用 户 创 建 的 相同 名 称 的 里 程 碑 会 互 
相 窗 蓄 。 


1. 显 式 推送 以 共 译 里 程 碑 


如 果 用 户 确实 需要 将 某 些 本 地 建立 的 里 程 碑 推送 到 远程 版 本 库 ， 
需要 在 git push 命 令 中 明确 地 表示 出 来 。 下 面 在 用 户 user1 的 工作 区 执行 
命令 ， 将 mytag 里 程 碑 共享 到 上 游 版 本 库 。 


五 


$git push origin mytag 

Total 0(delta 0),reused 0O(delta 0) 

To file:///path/to/repos/hello-world.git 
*[new tag]mytag- >mytag 


如 果 需 要 将 本 地 建立 的 所 有 里 程 碑 全 部 推送 到 远程 版 本 库 ， 可 以 
使 用 通配符 。 


$git push origin refs/tags/* 

Counting objects:2, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 
Writing objects:100%(2/2),687 bytes, done. 
Total 2(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(2/2),done. 

To file:///path/to/repos/hello-world.git 
*[new tag]mytag2- >mytag2 

*[new tag]mytag3- >mytag3 


再 用 命令 git ls-remote 查 看 上 游 版 本 库 的 引用 ， 会 发 现 本 地 建立 的 
三 个 里 程 碑 ， 已 经 能 够 在 上 游 中 看 到 了 。 
$git ls-remote origin my* 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
149b6344e80fc1i90bda5621cd71df391d3dd465e refs/tags/mytag2 
8a9f3d16ce2b4d39b5d694de10311207f289153f refs/tags/mytag2^{} 


5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
ebcf6d6b06545331df156687ca2940800a3c599d refs/tags/mytag3^{} 


2. 用 户 从 版 本 库 执 行 拉 回 操作 ， 会 目 动 获取 里 程 碑 么 ? 


用 户 user2 的 工作 区 中 如 果 执 行 git fetch 或 git pull 操 作 ， 能 目 动 将 用 
户 user1 推 送 到 共享 版 本 库 中 的 里 程 碑 获 取 到 本 地 版 本 库 么 ?下面 实践 
a 


(1) 进入 user2 的 工作 区 。 


$cd/path/to/user2/workspace/hello-world/ 


(2) 执行 git pull 命 令 ， 从 上 游 版 本 库 获 取 提交 。 


$git pull 

remote:Counting objects:5,done. 
remote:Compressing objects:100%(5/5),done. 
remote:Total 5(delta 0),reused 0(delta 0) 
Unpacking objects:100%(5/5),done. 

From file:///path/to/repos/hello-world 
3e6070e..ebcf6d6 master->origin/master 
*[new tag]mytag3- >mytag3 

From file:///path/to/repos/hello-world 
*[new tag]mytag- >mytag 


*[new tag]mytag2- >mytag2 
Updating 3e6070e..ebcf6d6 
Fast-forward 


(3) 可 见 执行 git pull 操 作 ， 能 够 在 获取 远程 共享 版 本 库 的 提交 的 
同时 ， 获 取 新 的 里 程 碑 。 下 面 的 命令 可 以 看 到 本 地 版 本 库 中 的 里 程 
碑 。 


$git tag-n1i-] my* 

mytag blank commit. 

mytag2 My first annotated tag. 
mytag3 My first GPG-signed tag. 


3. 里 程 碑 变 更 能 够 目 动 同步 吗 ? 


里 程 碑 可 以 被 强制 更 新 。 当 里 程 碑 被 改变 后 ， 已 经 获取 到 里 程 碑 
的 版 本 库 再 次 使 用 获取 或 拉 回 操作 ， 能 够 目 动 更 新 里 程 碑 吗 ? 管 案 是 
不 能 。 可 以 看 看 下 面 的 操作 。 


(1) 用 户 user2 强 制 更 新 里 程 碑 mytag2 。 


$git tag-f-m "user2 update this annotated tag." mytag2 HEADA^ 
Updated tag 'mytag2' (was 149b634) 


(2) 里 程 碑 mytag2 已 经 是 不 同 的 对 象 了 。 


$git rev-parse mytag2 
Qe6c780ffofe06635394db9dac6fb494833df8df 

$git cat-file-p mytag2 

object 8a9f3d16ce2b4d39b5d694de10311207f289153f 
type commit 


tag mytag2 
tagger User2<User2Q@moon.ossxp.com>Mon Jan 3 01:14:18 2011+0800 
User2 update this annotated tag. 


(3) 为 了 更 改 远程 共享 服务 器 中 的 里 程 碑 ， 同 样 需要 显 式 推送 。 
即 在 推送 时 写 上 要 推送 的 里 程 碑 名 称 。 
$git push origin mytag2 
Counting objects:1, done. 
Writing objects:100%(1/1),171 bytes, done. 
Total 1(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(1/1),done. 


To file:///path/to/repos/hello-world.git 
149b634. .0e6c780 mytag2- >mytag2 


(4) 切换 到 另外 一 个 用 户 userl 的 工作 区 。 


$cd/path/to/user1i/workspace/hello-world/ 


(5) 用 户 user1 执 行 拉 回 操作 ， 没 有 获取 到 新 的 里 程 碑 。 


$git pull 
Already up-to-date. 


(6) 用 户 user1l 必 须 显 式 地 执行 拉 回 操作 。 即 要 在 git pull 的 参数 中 
使 用 引用 表达 式 。 


所 谓 引 用 表达 式 殉 是 用 冒号 分 隔 的 引用 名 称 或 通配符 。 用 在 这 里 
代表 用 远程 共享 版 本 库 的 引用 refs/tag/mytag2 履 盖 本 地 版 本 库 的 同名 引 
用 。 


$git pull origin refs/tags/mytag2:refs/tags/mytag2 
remote:Counting objects:1,done. 

remote:Total 1(delta 0),reused 0(delta 0) 
Unpacking objects:100%(1/1),done. 

From file:///path/to/repos/hello-world 

-[tag update]mytag2- >mytag2 

Already up-to-date. 


天 于 里 程 碑 的 共 理 和 同步 操作 ， 看 似 很 烦琐 ， 但 用 心 体会 融会 感 
觉 到 Git 关 于 里 程 碑 共 享 的 设计 是 非常 合理 和 人 性 化 的 : 


里 程 碑 共 至 ， 必 须 显 式 的 推送 。 即 在 推送 命令 的 参数 中 ， 标 明 要 
推送 哪个 里 程 碑 。 


显 式 推 送 是 防止 用 户 随意 推送 里 程 碑 导 致 共享 版 本 库 中 里 程 碑 泛 
秆 的 方法 。 当 然 还 可 以 参考 第 5 篇 “第 30 章 Gitolite 服 务 架 设 ” 的 相关 章节 
为 共 至 版 本 库 添加 授权 ， 只 人 允许 部 分 用 户 同 服务 如 推送 里 程 碑 。 


执行 获取 或 拉 回 操作 ， 目 动 从 远程 版 本 库 获 取 新 里 程 碑 ， 并 在 本 
地 版 本 库 中 创建 。 


获取 或 拉 回 操作 ， 只 会 将 获取 的 远程 分 文 所 包含 的 新 里 程 碑 同 步 
到 本 地 ， 而 不 会 将 远程 版 本 库 的 其 他 分 文中 的 里 程 碑 获取 到 本 地 。 这 
既 方 便 了 里 程 碑 的 取得 ， 又 防止 本 地 里 程 夏 因 同 步 远 程 版 本 库 而 沁 


小 。 


如 果 本 地 已 有 同名 的 里 程 碑 ， 默 认 不 会 从 上 游 同 步 里 程 碑 ， 即 使 
两 者 里 程 碑 的 指向 十 不 同 的 。 理 解 这 一 点 非常 重要 。 这 也 束 要 求 里 程 
人 碑 一 旦 共 诗 ， 束 不 要 再 修改 。 


17.6 ”删除 远程 版 本 库 的 里 程 碑 


假如 回 远 程 版 本 库 推送 里 程 碑 后 ， 忽 然 发 现 里 程 碑 创 建 在 了 错误 
的 提交 上 ， 为 了 防止 其 他 人 获取 到 错误 的 里 程 碑 ， 应 该 尽快 将 里 程 碑 
删除 。 


删除 本 地 里 程 碑 非常 简单 ， 使 用 git tag-d<tagname> 就 可 以 了 ， 
但 是 如 何 撤销 已 经 推送 到 远程 版 本 库 的 里 程 碑 呢 ? 需要 登录 到 服务 器 
上 吗 ? 或 者 需要 麻烦 管理 员 吗 ? 不 必 ! 可 以 直接 在 本 地 版 本 库 执 行 命 
令 删除 远程 版 本 库 中 的 里 程 碑 。 


使 用 git push 命 令 可 以 删除 远程 版 本 库 中 的 里 程 碑 。 用 法 如 下 : 


命令 :git push< remote_ur1I> :<tagname > 


该 命令 的 最 后 一 个 参数 实际 上 十 一 个 引用 表达 式 ， 引 用 表达 式 一 
般 的 格式 为 <ref>: <ref>。 该 推送 命令 使 用 的 引用 表达 式 冒 号 前 的 
引用 被 省 略 ， 其 含义 是 将 一 个 空 值 推 送 到 远程 版 本 库 对 应 的 引用 中 ， 
亦 即 删除 远程 版 本 库 中 相关 的 引用 。 这 个 命令 不 但 可 以 用 于 删除 里 程 
碑 ， 在 下 一 章 还 可 以 用 它 删 除 远 程 版 本 库 中 的 分 文 。 


下 面 演示 在 用 户 userl 的 工作 区 执行 下 面 的 命令 删除 远程 共享 版 本 
库 中 的 里 程 碑 mytag2 。 


(1) 切换 到 用 户 user1 工 作 区 。 


$cd/path/to/user1i/workspace/hello-world 


(2) 执行 推送 操作 删除 远程 共享 版 本 库 中 的 里 程 碑 。 


$git push origin:mytag2 
To file:///path/to/repos/hello-world.git 
-[deleted]jmytag2 


(3) 查看 远程 共享 库 中 的 里 程 碑 ， 发 现 mytag2 的 确 已 经 被 删除 。 


$git ls-remote origin my* 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
ebcf6d6b06545331df156687ca2940800a3c599d refs/tags/mytag3^{} 


17.7 里程碑 命名 规范 


在 正式 项 目的 版 本 库 管 理 中 ， 要 为 里 程 碑 创 建 订立 一 些 规 则 ， 庄 
如 : 


对 创建 里 程 碑 进行 权限 控制 ， 参 考 后 面 Git 服 务 絮 染 设 的 相关 革 


节 。 


不 要 使 用 轻 量 级 里 程 碑 〈 只 用 于 本 地 临时 性 里 程 碑 ) ， 而 是 要 使 
用 融 说 明 的 里 程 碑 ， 甚 至 要 求 必 须 使 用 带 签 名 的 里 程 碑 。 


如 采 使 用 毫 签名 的 里 程 碑 ， 可 以 考虑 设置 专用 账户 ， 使 用 专用 的 
私 钥 创建 签名 。 


里 程 碑 的 命名 要 使 用 统一 的 风格 ， 并 很 容易 和 最 终 产 品 显 示 的 版 
本 号 相对 应 。 


Git 的 里 程 碑 命名 还 有 一 些 特殊 的 约定 需要 遵守 。 实 际 上 ， 下 面 的 
这 些 约定 对 于 下 一 章 要 介绍 的 分 文 及 任何 其 他 引用 均 适 用 : 


不 要 以 符号 “- "开头 。 以 免 在 命令 行 中 被 当成 命令 的 选项 。 


可 以 包含 路 径 分 隅 符 “”， 但 是 路 径 分 隔 符 不 能 位 于 最 后 。 


使 用 路 径 分 隔 符 创建 tag 实 际 上 会 在 引用 目录 下 创建 子 目 孙 。 例 如 
名 为 demo/v1.2.1 的 里 程 碑 ， 束 会 创建 目录 .git/refs/tags/demo 并 在 该 目录 
下 创建 引用 文件 v1.2.1。 


不 能 出 现 两 个 连续 的 点 “..”。 因为 两 个 连续 的 点 被 用 于 表示 有 版 本 苑 
围 ， 当 然 更 不 能 使 用 三 个 连续 的 点 。 


如 果 在 里 程 碑 命 名 中 使 用 了 路 径 分 隔 符 “”， 怠 不 能 在 任何 一 个 分 
隅 路 径 中 以 点 “.” 开 头 。 这 是 因 为 里 程 碑 在 用 简写 格式 表达 时 ， 可 能 造 
成 以 一 个 上 后“” 开 头 。 这 样 的 引用 名 称 在 用 作 版 本 范围 的 最 后 一 个 版 本 
时 ， 本 来 两 点 操作 符 变 成 了 三 点 操作 符 ， 从 而 造成 疏 义 。 


不 能 在 里 程 碑 名 称 的 最 后 出 现 点 <.”。 否则 作为 第 一 个 参数 出 现在 
表示 版 本 范围 的 表达 式 中 时 ， 本 来 版 本 范围 表达 式 可 能 用 的 是 两 点 操 
作 符 ， 结 果 被 误 作 三 点 操作 符 。 


J 


不 能 使 用 特殊 字符; 训 空格 波浪 全 2 有 守 竹 W 
EE 0 0 i a 
小 于 \040 (32) 的 Ascii 码 都 不 能 使 用 。 


村 
过 


这 是 因为 波浪 线 “~” 和 脱 字 符 “^” 都 用 于 表示 一 个 提交 的 祖先 拓 
交 。 导 号 被 用 作 引 用 表达 式 来 分 隔 两 个 不 同 的 引用 ， 或 者 用 于 分 隔 引 
用 代表 的 树 对 象 和 该 目录 树 中 的 文件 。 问 号 、 星 号 和 方 括号 在 引用 表 
达 式 中 都 被 用 作 通 配 符 。 


不 能 以 "lock" 为 结尾 。 因 为 以 "lock" 结 尾 的 文件 是 里 程 碑 操作 过 
程 中 的 临时 文件 。 


不 能 包含 “<@f{" 字 串 。 否 则 易 和 reflog 的 "@{<num>}" 语 法 相 混 
消 。 

不 能 包含 反 斜 线 “"。 因 为 反 斜 线 用 于 命令 行 或 shell 脚 本 会 造成 意 
2 

Git 还 专门 为 检查 引用 名 称 是 否 符合 规范 提供 了 一 个 命令 ，git 


check-ref-format。 若 该 命令 返回 值 为 0， 则 3 引用 名 称 符合 规范 ， 若 返回 
值 为 1， 则 不 符合 规范 。 


$git check-ref-format refs/tags/.name||echo "返回 $? ,不 合法 的 引用 
返回 1, 不 合法 的 引用 


1.Linux 中 的 里 程 碑 


Linux 内 核 项 目 无 疑 是 使 用 Git 版 本 库 时 间 节 和 久远， 也 十 最 重量 级 
的 项 目 。 研 究 Linux 内 核 项 目 本 吴 的 里 程 碑 命名 和 管理 ， 无 疑 会 为 目 己 
的 项 目 提供 借鉴 。 


(1) 首先 看 看 Linux 中 的 里 程 碑 命名 。 可 以 看 到 里 程 碑 都 是 以 字 
vs 


$git ls-remote--tags\ 


git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6- 
stable.git\ 
V2.6.36* 


25427f38d3b791d986812cb81c68df38e8249ef8 refs/tags/v2.6.36 
f6f94e2ab1b33f0082ac22d71f66385a60d8157f refs/tags/v2.6.36^{} 
8ed88d401f908a594cd74a4f2513bofabd32b699 refs/tags/v2.6.36-rci 
da5cabf80e2433131bfoed8993abcof7ea618c73 refs/tags/v2.6.36- 


rci^{} 


7619e63f48822b2c68d0e108677340573873fb93 refs/tags/v2.6.36-rc8 
cd07202cc8262e1669edff0d97715f3dd9260917 refs/tags/v2.6.36- 
rc8^{} 


9d389cb6dcae347cfcdadf2alec5e66fc7a667ea refs/tags/v2.6.36.1 
bf6ef02e53e18dd14798537e530e00b80435ee86 refs/tags/v2.6.36.1^{} 
ee7b38c91f3d718ea4035a331c24a56553e90960 refs/tags/v2.6.36.2 
a1346c99fc89f2b3d35c7d7e2e4aef8ea4124342 refs/tags/v2.6.36.2^{} 


(2) 以 -rc<num> 为 后 缀 的 是 先 于 正式 版 发 布 的 预 发 布 版 本 。 


可 以 看 出 这 个 里 程 碑 是 一 个 带 签名 的 里 程 碑 。 关 于 此 里 程 碑 的 
明 也 是 再 简练 不 过 了 。 


$git Show v2.6.36-rc1 

tag v2.6.36-rc1 

Tagger:Linus Torvalds<torvalds@linux-foundation.org> 
Date:Sun Aug 15 17:42:10 2010-0700 

Linux 2.6.36-rcl 


Version:GnuPG v1.4.10(GNU/Linux) 
iEYEABECAAYFAkxoiwgACgkQF3YsRNbiHLtYKQCfQSIVcj2hvLj6IWgP9xK2FE7T 
bPoAniJ1CjbwLxQBudRi71FvubqPLuVC 

=iuls 


commit da5cabf80e2433131bfoed8993abcof7ea618c73 
Author:Linus Torvalds<torvalds@linux-foundation.org> 
Date:Sun Aug 15 17:41:37 2010-0700 

Linux 2.6.36-rcl 

diff--git a/Makefile b/Makefile 

index 788111d..f3bdff8 100644 

---a/Makefile 

+++b/Makefile 

QQ@-1, 7+1, 7@@ 


VERSION=2 
PATCHLEVEL=6 
-SUBLEVEL=35 
-EXTRAVERSION= 
+SUBLEVEL=36 
+EXTRAVERSION=-rc1 
NAME=Sheep on Meth 
#*DOCUMENTATION* 


(3) 正式 发 布 版 去 掉 了 预 发 布 版 的 后 级 。 


$git show v2.6.36 

tag v2.6.36 

Tagger:Linus Torvalds<torvalds@linux-foundation.org> 
Date:wed Oct 20 13:31:18 2010-0700 

Linux 2.6.36 

The latest and greatest,and totally bug-free.At least until 


2.6.37 


of 


comes along and shoves it under a speeding train like some kind 
a 

bully. 

----- BEGIN PGP SIGNATURE----- 

Version:GnuPG v1.4.10(GNU/Linux) 
iEYEABECAAYFAky/UcwACgkQF3YsRnbiHLvg/ACffKkjAb1ifD6fpqcHbSijHHpbP3 
4SkANR4xOy7iKhmfS50ZrVsOkFFTUBHG 

=JD3Zz 


commit f6f94e2ab1b33f0082ac22d71f66385a60d8157f 
Author:Linus Torvalds<torvalds@linux-foundation.org> 
Date:wed Oct 20 13:30:22 2010-0700 

Linux 2.6.36 

diff--git a/Makefile b/Makefile 

index 7583116. .860c26a 100644 

---a/Makefile 

+++b/Makefile 

QQ@-1, 7+1, 760 

VERSION=2 

PATCHLEVEL=6 SUBLEVEL=36 

-EXTRAVERSION=-rc8 

+EXTRAVERSION= 

NAME=Flesh-Eating Bats with Fangs 
#*DOCUMENTATION* 


(4) 正式 发 布 后 的 升级 /修正 版 本 是 通过 最 后 一 位 数字 的 变动 来 
体现 的 。 


$git show v2.6.36.1 

tag v2.6.36.1 

Tagger:Greg Kroah-Hartman<gregkh@suse.de> 
Date:Mon Nov 22 11:04:17 2010-0800 

This is the 2.6.36.1 stable release 


Version:GnuPG v2.0.15(GNU/Linux) 
iEYEABECAAYFAkzqvrIACgkQMUfUDdst+ym9VQCgmE1LK2eC/LE9HKkscsxL1X62P 
8FOANRI28EHENLXC+FBPt+AFWoT9f1N8 

=BX50 

入 END PGP SIGNATURE----- 

commit bf6ef02e53e18dd14798537e530e00b80435ee86 
Author:Greg Kroah-Hartman<gregkh@suse.de> 
Date:Mon Nov 22 11:03:49 2010-0800 

Linux 2.6.36.1 

diff--git a/Makefile b/Makefile 

index 860c26a..dafd22a 100644 
---a/Makefile 

+++b/Makefile 

QQ@-1, 7+1, 7@@ 

VERSION=2 

PATCHLEVEL=6 

SUBLEVEL=36 

-EXTRAVERSION= 

+EXTRAVERSION=.1 

NAME=Flesh-Eating Bats with Fangs 
#*DOCUMENTATION* 


2.Android 项 目 


看 看 其 他 项 目的 里 程 碑 命名 ， 会 发 现 不 同 项 目 关 于 里 程 碑 的 命名 
各 不 相同 。 但 是 对 于 同一 个 项 目 要 在 里 程 碑 命 名 上 遵照 同一 标准 ， 并 
能 够 和 软件 版 本 号 正确 地 对 应 。 


Android 项 目 是 一 个 非常 有 特色 的 使 用 Git 版 本 库 的 项 目 ， 在 后 面 
会 用 两 章 介绍 Android 项 目 为 Git 带 来 的 两 个 新 工具 。 看 看 Android 项 日 
的 里 程 碑 编号 对 自己 版 本 麻 的 管理 有 无 启发 。 


(1) 看 看 Android 项 目 中 的 里 程 碑 命名 ， 会 发 现 其 里 程 碑 的 命名 
格式 为 android- < 大 版 本 号 >_r< 小 版 本 号 > 。 


$git ls-remote--tags\ 

git://android.git.kernel.org/platform/manifest.git\ 

android-2.2* 

6a03ae8f564130cbb4a11acfc49bd705df7c8df6 refs/tags/android- 
2.2.1_ri 

599e242dea48f84e2f26054b0d1721e489043440 refs/tags/android- 
2.2.1_r1i^{} 

656ba6fdbd243153af6ec31017de38641060bf1ie refs/tags/android- 
2.2_r1 

27cd0e346d1f3420c5747e01d2cb35e9ffd025ea refs/tags/android- 
2.2_r1i^{} 

f6b7c499be268f1613d8cd7of2a05c12e01bcb93 refs/tags/android- 
272- :1 

bd3e9923773006a0a5f782e1f21413034096c4b1 refs/tags/android- 
2.2_r1.1^{} 

03618e01lec9bddo6fd8fe9afdbdcbaf4b84092c5 refs/tags/android- 
2.2_r1.2 

ba7111e1d6fd26ab150bafa029fd5eab8196dad1 refs/tags/android- 
2.2_r1.2^{} 

e03485e978ce1662a1285837f37ed39eadaedb1d refs/tags/android- 
252 TL.3 

7386d2d07956be6e4f49a7e83eafb12215e835d7 refs/tags/android- 
2.2_r1.3^{} 


(2) 里 程 碑 的 创建 过 程 中 使 用 了 专用 账号 和 GnuPG 签 名 。 


$git show android-2.2_r1 

tag android-2.2_r1i 

Tagger:The Android Open Source Project<initial- 
contribution@android.com> 


Date:Tue Jun 29 11:28:52 2010-0700 
Android 2.2 release 1 


Version:GnuPG v1.4.6(GNU/Linux) 
ID8DBQBMKJjtm6K0O/XgZzqxDngRAJLBUAJ9QwgFbUL592FgdRZLTLLbzhKsSQ8ACffQu5 
Mjxg5X9oc+7N1DfdU+pmoOcI= 

=ONGO 


commit 27cdoe346d1f3420c5747e01d2cb35e9ffd025ea 

Author:The Android Open Source Project<initial- 
contribution@android.com> 

Date:Tue Jun 29 11:27:23 2010-0700 

Manifest for android-2.2_r1i 

diff--git a/default.xml b/default.xml 

index 4f21453..aaa26e3 100644 

---a/default .xml 

+++b/default .xml 

@@-3,7+3, 766 

<remote name= "korg" 

fetch="git://android.git.kernel.org/" 

review="review.source.android.com"/> 

-<default revision="froyo" 

+<default revision="refs/tags/android-2.2_r1" 

remote="korg"/> 


第 18 章 ”Git 分 支 


分 支 是 我 们 的 老 朋友 了 ， 第 6 章 、 第 7 章 和 第 8 章 就 已 经 从 实现 原理 
上 介绍 了 分 支 。 您 想必 已 经 知道 了 分 支 master 的 存在 方式 无 非 就 是 在 
目录 .gitrefs/heads 下 的 文件 (或 称 引用 ) 而 已 。 也 看 到 了 分 支 master 的 
指向 如 何 随 着 提交 而 变化 ， 如 何 通过 git reset 命 令 而 重 置 ， 以 及 如 何 使 
用 git checkout 命 令 而 检 出 。 


之 前 的 章节 都 只 用 到 了 一 个 分 文 : master 分 文 ， 而 在 本 章 会 接触 
到 多 个 分 文 。 会 从 应 用 的 角度 上 介绍 分 文 的 几 种 不 同类 型 : 发 布 分 
文 、 特 性 分 文 和 卖主 分 文 。 在 本 章 可 以 学 习 到 如 何 对 多 分 文 进行 操 
作 ， 如 何 创 建 分 支 ， 如 何 切 换 到 其 他 分 支 ， 以 及 分 文 之 间 的 合并 、 变 


18.1 代码 管理 之 殉 


分 文 是 代码 管理 的 利器 。 如 果 没有 有 效 的 分 文 管理 ， 代 码 管 理 整 
适应 不 了 复杂 的 开发 过 程 和 项 目的 需要 。 在 实际 的 项 目 实践 中 ， 单 一 
分 文 的 单线 开发 模式 远 远 不 够 ， 因 为 : 


成 功 的 软件 项 目 大 多 要 经 过 多 个 开发 周期 ， 发 布 多 个 软件 版 本 。 
每 个 已 经 发 布 的 版 本 都 可 能 发 现 Bug， 这 就 需要 对 历史 版 本 进行 更 


改 ” 


有 前 脆性 的 项 目 管理 ， 新 版 本 的 开发 往往 是 和 当前 版 本 同步 进行 
的 。 如 果 两 个 版 本 的 开发 都 混杂 在 master 分 文中 ， 肯 定 会 是 一 场 灾 
难 。 


如 采 产 品 要 针对 不 同 的 客户 定制 ， 肯 定 是 布 望 客户 越 多 越 好 。 如 
果 所 有 的 客户 定制 都 访 杂 在 一 个 分 文中 ， 必 定 会 市 来 混乱 。 如 采 使 用 
多 个 分 文 管理 不 同 的 定制 ， 但 春 是 管理 不 善 ， 分 文 之 间 定 制 功 能 的 迁 
移 束 会 成 为 头痛 的 问题 。 


即便 十 所 有 成 员 都 在 为 同一 个 项 目的 同一 个 版 本 进行 工作 ， 每 个 
人 领受 任务 却 不 尽 相 同 ， 有 的 任务 开发 周期 会 很 长 ， 有 的 任务 需要 对 
软件 染 构 进行 较 大 的 修改 ， 如 果 所 有 人 都 工作 在 同一 分 支 中 ， 束 会 因 
为 过 多 过 频 的 冲突 导致 效率 低下 。 


敏捷 开发 (不管 是 极限 编程 XP 还 是 Scrum 或 其 他 ) 是 最 有 效 的 项 
目 管 理 模式 ， 其 最 有 效 的 一 个 实践 束 是 快速 述 代 、 每 晚 编 译 。 如 末 不 
能 将 项 目的 各 个 功能 模块 的 开发 通过 分 文 进行 隔离 ， 在 软件 集成 上 丈 
会 遭遇 困难 。 


18.1.1 发 布 分 支 


在 2006 年 我 接触 到 一 个 项 目 团 队 ， 使 用 Subversion 做 版 本 控制 。 最 
为 困扰 项 目 经 理 的 是 刚刚 修正 产品 的 一 个 Bug， 马 上 又 会 接二连三 地 
发 现 新 的 Bug。 在 访谈 开发 人 员 ， 询 问 开 发 人 员 是 如 何 修 正 Bug 的 时 
候 ， 开 发 人 员 的 回答 让 我 大 吃 一 惊 :“ 当 发 现 产品 出 现 Bug 的 时 
候 ， 我 要 中 断 当 前 的 工作 ， 把 我 正在 开发 的 新 功能 的 代码 注释 掉 ， 然 后 再 去 修改 Bug， 修 改 
好 就 生成 一 个 war 包 《〈Java 开发 网 站 项 目 ) 给 运 维 部 门 ， 扔 到 网 站 上 去 。” 


于 是 我 就 画 了 下 面 的 一 个 图 〈 图 18-1)， 大 致 描述 了 这 个 困 队 进行 Bug 修正 的 过 程 ， 从 
中 可 以 很 容易 地 看 出 问题 的 端倪 。 这 个 图 对 于 Git 甚至 其 他 版 本 库 控制 系统 同样 适用 ， 


OD 2006719 » 熏 


@ 100k719 一 A 一 


A 


F1.1 fix} PF12 fix2 


图 18-1 为 什么 Bug 没完 没 了 


说 明 ; 

口 图 18-1 中 的 图 示 外 ， 开 发 者 针对 功能 1 做 了 一 个 提交 ， 编 号 “F1.1”。 这 时 客户 报告 
已 发 布 的 产品 出 现 了 Bug。 

口 于 是 开发 者 匆忙 地 干 了 起 来 ， 图 示 外 显示 了 该 开发 者 修正 Bug 的 过 程 : 将 新 提交 的 针 
对 功能 1 的 代码 “F1.1” 注 释 泉 ， 然 后 提交 一 个 修正 Bug 的 提交 (编号 : fix1)。 

口 开 发 者 编译 出 已 发 布 软件 的 修订 版 交 给 客户 ， 接 着 开始 功能 1 的 开发 。 图 示 国 显示 了 
开发 者 针对 功能 1 做 出 了 一 个 新 的 提交 “F1.2”。 

口 客户 再 次 在 已 发 布 版 本 中 发 现 一 个 Bug。 开 发 者 再 次 开始 Bug 修正 工作 - 

口 图 示 国 和 图 示 回 显示 了 此 工作 模式 下 非常 容易 在 修复 一 个 Bug 的 时 候 引 入 新 的 Bug: 

口 图 示 @ 的 问题 在 于 开发 者 注释 功能 1 的 代码 时 ， 不 小 心 将 “fix1” 的 代码 也 注释 掉 了 ， 
导致 曾经 修复 的 Bug 在 已 发 布 软件 的 修订 版 中 重 现 。 

口 图 示 加 的 问题 在 于 开发 者 没有 将 功能 1 的 代码 剔 出 干 淘 ， 导 致 在 已 发 布 产品 的 修订 版 
本 中 引入 了 不 完整 和 不 需要 的 功能 代码 。 用 户 可 能 看 到 一 个 新 的 但 是 不 能 使 用 的 菜单 
项 ， 黄 至 更 模 ， 

使 用 版 本 控制 系统 的 分 支 功 能 ， 可 以 避免 对 已 发 布 的 软件 版 本 进行 Bug 修正 时 引入 新 功 


能 的 代码 ， 或 者 因 误 删 其 他 Bug 修正 代码 导致 已 修复 问题 重 现 。 在 这 种 情况 下 创建 的 分 支 有 
一 个 专 有 的 名 称 : Bugfix 分 支 或 发 布 分 支 (Release Branch)。 之 所 以 称 为 发 布 分 支 ， 是 因为 
在 软件 新 版 本 发 布 后 经 常 使 用 此 技术 进行 软件 维护 ， 发 布 升级 版 本 。 

图 18-2 演示 了 如 何 使 用 发 布 分 支 应 对 Bug 修正 的 过 程 。 


时 间 线 
路 2006/16 > 
F1.1 
fix1 
@ 200615 | > 
F1.1 
flixli 
G) 200W15 | 秘 3 
Fi1,.1 fx1i 
有 有 XI 
@ 2006/10 | > Ea) 
F1.1 fix1 F1i.2 
fixi fix2 
® 2006/10 
Fi1.1 fix1i Fi.2 fix2 


图 18-2 ”使 用 发 布 分 支 的 Bug 修正 过 程 


说 明 : 

口 图 18-2 中 的 图 示 @@， 可 以 看 到 开发 者 创建 了 一 个 发 布 分 支 (Bugfix 分 支 )， 在 分 支 中 
提交 修正 代码 “fix1”。 注 总 此 分 支 是 自 上 次 软件 发 布 时 最 后 一 次 提交 进行 创建 的 ， 
此 分 支 中 没有 包含 开发 者 为 新 功能 所 做 的 提交 “Fl1.1”， 是 一 个 “干净 ”的 分 支 。 

口 图 示 因 可 以 看 出 从 发 布 分 支 向 主线 做 了 一 次 合并 ， 这 是 因为 在 主线 上 也 同样 存在 该 
Bug， 和 需要 在 主线 上 也 做 出 相应 的 更 改 ， 

口 图 示 思 ， 开 发 者 继续 开发 ， 针 对 功能 1 执行 了 一 个 新 的 提交 ， 编 号 “F1.2”。 这 时 ， 
客户 报告 有 新 的 Bug。 

口 继续 在 发 布 分 支 上 进行 Bug 修正 ， 参 考 图 示 回 。 当 修正 完成 〔 提 交 “fix2”) 时 ， 基 
于 发 布 分 支 创建 一 个 新 的 软件 版 本 发 给 客户 。 不 要 忘 了 向 主线 合并 ， 因 为 同样 的 Bug 


可 能 在 主线 上 也 存在 。 
关于 如 何 基于 一 个 历史 提交 创建 分 支 ， 以 及 如 何在 分 支 之 间 进 行 合并 ， 在 本 章 后 面 的 内 
容 中 会 详细 介绍 ， 


18.1.2 ”特性 分 支 


有 这 么 一 个 软件 项 目 ， 项 目 已 经 延期 了 可 是 还 是 看 不 到 一 点 要 完成 的 样子 。 最 终老 板 变 
得 有 些 不 耐烦 了 ， 说 道 : “那么 就 砍 掉 一 些 功能 吧 ”。 项 目 经 理 听 闻 一 阵 眩 荣 ， 因 为 项 目 经 理 
知道 自己 负责 的 这 个 项 目 采用 的 是 单一 主线 开发 ， 要 将 一 个 功能 从 中 撤销 ， 工 作 基 非常 大 ， 
而 且 还 可 能 会 牵涉 到 其 他 相关 模块 的 变更 。 


图 18-3 没有 使 用 分 支 导致 项 目 拖延 


说 明 : 

口 图 18-3 中 的 图 示 久 ， 用 圆圈 代表 功能 1 的 历次 提交 ， 用 三 角 代 替 功 能 2 的 历次 提交 。 
因为 所 有 开发 者 都 在 主线 上 工作 ， 所 以 提交 温 杂 在 一 起 ， 

口 当 老板 决定 功能 2 不 在 这 一 版 本 的 产品 中 发 布 ， 延 期 到 下 一 个 版 本 时 ， 功 能 2 的 开发 
者 做 了 一 个 或 者 若干 个 ) 反 向 提交 ， 即 图 示 @@ 中 的 倒 三 角 (代号 为 “F2.X”) 标识 
的 反 向 提交 ， 将 功能 2 的 所 有 历史 提交 全 部 撤销 ， 

口 图 示 四 表示 除了 功能 2 外 的 其 他 开发 继续 进行 ， 

那么 负责 开发 功能 2 的 开发 者 干什么 呢 ? 或 者 放 一 个 长 假 ， 或 者 在 本 地 开发 ， 与 版 本 库 

隔离 ， 即 不 向 版 本 库 提交 ， 直 到 延期 的 项 目 终于 发 布 之 后 再 将 代码 提交 。 这 两 种 方法 都 是 不 
可 取 的 ,尤其 是 后 一 种 隔离 开发 最 危险 ， 如 果 因 为 病毒 感染 、 文 件 误 铀 、 磁 盘 损 坏 ， 就 会 导 
致 全 部 工作 损失 始 尽 。 我 管理 过 的 一 个 项 目 组 就 曾经 遇 到 过 这 样 的 情况 : 

采用 分 支 将 革 个 功能 或 模块 的 开发 与 开发 主线 独立 出 来 ， 是 解决 类 似 问 题 的 办 法 ， 这 种 

用 途 的 分 支 被 称 为 特性 分 支 (Feature Branch) 或 主题 分 支 (Topic Branch)。 图 18-4 就 展示 
了 如 何 使 用 特性 分 支 帮助 纠正 要 延期 的 项 目 ， 协 同 多 用 户 的 开发 。 


© 
ra.1 F2.2' F2.3 
® 
F1.1 F2.1 F1.2 F2.2 F2.X Fl1.3 F1.4 F1.5 
图 18-4 使 用 特性 分 支 协 间 多 功能 开发 
说 明 : 


口 图 18-4 中 的 图 示 @@ 和 前 面 的 一 样 ， 都 是 多 个 开发 者 的 提交 混杂 在 开发 主线 中 。 

口 图 示 @ 是 当 得 知 功 能 2 不 在 此 次 产品 发 布 中 后 ， 功 能 2 的 开发 者 所 做 的 操作 ， 

口 首 先 ， 功 能 2 的 开发 者 提交 一 个 (或 若干 个 ) 反问 提交 ， 将 功能 2 的 相关 代码 全 部 撤 
销 。 图 中 倒 三 角 〔( 代 号 为 <F2.X”) 的 提交 就 是 一 个 反 向 提交 ， 

口 接着 ， 功 能 2 的 开发 者 从 反 向 提交 开始 创建 一 个 特性 分 支 。 

口 最 后 ， 功 能 2 的 开发 者 将 功能 2 的 历史 提交 拣选 到 特性 分 支 上 。 对 于 Git 可 以 使 用 拒 
选 命令 git cherry-pick。 

口 图 示 加 中 可 以 看 出 包括 功能 2 在 内 的 所 有 功能 和 模块 都 继续 提交 ， 但 是 提交 的 分 支 各 
不 相同 。 功 能 2 的 开发 者 将 代码 提交 到 特性 分 支 上 ， 其 他 开发 者 还 提交 到 主线 上 . 


那么 在 什么 情况 下 使 用 特性 分 支 呢 ? 试验 性 、 探 索性 的 功能 开发 应 该 为 其 建立 特性 分 
支 。 功 能 复杂 、 开 发 周期 长 《有 可 能 在 本 次 发 布 中 取消 ) 的 模块 应 该 为 其 建立 特性 分 支 。 会 
更 改 软件 体系 架构 ， 破 坏 软件 集成 ， 或 者 容易 导致 冲突 、 影 响 他 人 开发 进度 的 模块 ， 应 该 为 
其 建立 特性 分 支 。 

在 使 用 CVS 或 Subversion 等 版 本 控制 系统 建立 分 支 时 ， 或 者 因为 太 慢 (CVS) 或 者 因 
为 授权 原因 需要 找 管理 员 进 行 操作 ， 非 常 的 不 方便 。Git 的 分 支管 理 就 方便 多 了 ， 一 是 开发 
者 可 以 在 本 地 版 本 库 中 随心 所 欲 地 创建 分 支 ， 二 是 管理 员 可 以 对 共享 版 本 库 进 行 设置 允许 开 
发 者 创建 特定 名 称 的 分 支 ， 这 样 开发 者 的 本 地 分 支 可 以 推送 到 服务 器 实现 数据 的 备份 。 关 于 
Git 服务 器 的 分 支 授权 参照 本 书 第 5 篇 的 Gitolite 服务 器 架设 的 相关 章节 : 


18.1.3 ”卖主 分 文 


有 的 项 目 要 引用 到 第 三 方 的 代码 模块 并 且 需 要 对 其 进行 定制 ， 有 的 项 目 芷 至 整个 就 是 基 
于 茶 个 开源 项 目 进行 的 定制 。 如 何 有 效 地 管理 本 地 定制 和 第 三 方 (上 游 ) 代 码 的 变更 就 成 为 


了 一 个 难题 。 卖 主 分 支 (Vendor Branch) 可 以 部 分 解决 这 个 难题 . 
所 请 卖主 分 支 ， 就 是 在 版 本 库 中 创建 一 个 专门 和 和 上游 代 码 进 行 同步 的 分 支 ， 一 旦 有 上 游 
代码 发 布 就 检 入 到 卖主 分 支 中 。 图 18-5 就 是 一 个 典型 的 卖主 分 支 工 作 流 程 。 


2.0 v3.0 


图 18-5 卖主 分 支 工作 流程 


说 明 : 

口 在 主线 上 检 入 上 游 软 件 版 本 1.0 的 代码 。 在 图 中 标记 为 v1.:0 的 提交 即 是 ， 

口 然后 在 主线 上 进行 定制 开发 ，cl、c2 分 别 代表 历次 定制 提交 。 

口 当 上 游 有 了 新 版 本 发 布 后 ， 例 如 2.0 版 本 ， 就 将 上 游 新 版 本 的 源 代 码 提 交 到 卖主 分 支 

中 。 图 中 标记 为 x? .0 的 提交 即 是 。 

口 然后 在 主线 上 合并 卖主 分 支 上 的 新 提交 ， 合 并 后 的 提交 显示 为 M1 。 

如 果 定 制 较 少 ， 使 用 卖主 分 支 可 以 工作 得 很 好 ， 但 是 如 果 定 制 的 内 容 非常 多 ， 在 合并 的 
时 候 就 会 退 到 非常 多 的 冲突 。 定 制 的 代码 越 多 、 混 杂 的 越 厉害 ， 冲 突 解 决 就 越 困 难 . 

本 童 的 内 容 尚 不 能 针对 复杂 的 定制 开发 给 出 满意 的 版 本 控制 解决 方案 ， 本 书 第 4 篇 的 
“第 22 章 Topgit 协同 模型 ”会 介绍 一 个 针对 复杂 定制 开发 的 更 好 的 解决 方案 . 


18.2 ”分 文 命令 概述 


在 Git 中 分 支管 理 使 用 命令 git branch。 该 命令 的 主要 用 法 如 下 ， 


用 法 1; gqit branch 
用 法 2 ; git branch <branchname> 
用 法 3: qit branch <branchname> <start-point> 


用 法 4: 9it branch -d <branchname> 
用 法 5; 9qit branch -D <branchname> 
用 法 6: 9it branch -m <oldbranch> <newbranch> 
用 法 7 了 7: qit branch -M <oldbranch> <newbranch> 


说 明 : 

口 用 法 1 用 于 显示 本 地 分 支 列 表 。 当 前 分 支 在 输出 中 会 显示 为 特别 的 颜色 ， 并 用 星 号 
“*” 标 识 出 来 。 

口 用 法 2 和 用 法 3 用 于 创建 分 支 。 用 法 2 基于 当前 头 指针 “HEAD) 指向 的 提交 创建 分 
支 ， 新 分 支 的 分 支 名 为 <hranchname>。 用 法 3 基于 提交 <start-point> 创建 新 
分 支 ， 新 分 支 的 分 支 名 为 <branchname>。 

口 用 法 4 和 用 法 5 用 于 删除 分 支 。 用 法 4 在 删除 分 支 <branchname> 时 会 检查 所 要 
删除 的 分 支 是 否 已 经 合并 到 其 他 分 支 中 ， 否 则 拒绝 删除 。 用 法 5 会 强制 删除 分 支 


<branchname > ， 即 使 该 分 支 没有 合并 到 任何 一 个 分 支 中 。 


用 法 6 和 用 法 7 用 于 重 命名 分 支 。 如 果 版 本 库 中 已 经 存在 名 为 < 
newbranch> 的 分 支 ， 用 法 6 拒绝 执行 重 命名 ， 而 用 法 7 会 强制 执行 。 


下 面 就 通过 "Hello World" 项 目 演 示 Git 的 分 支管 理 。 


18.3 "Hello World" 开 发 计划 


上 一 章 从 Github 上 上 检 出 的 hello-world 包 含 了 一 个 C 语 言 开发 的 应 
用 ， 现 在 假设 项 目 hello-world 做 产品 发 布 ， 版 本 号 定 为 1.0， 则 进行 下 
面 的 里 程 碑 操作 。 


(1) 为 hello-world 创 建 里 程 碑 v1.0 。 


$cd/path/to/user1i/workspace/hello-world/ 
$git tag-m "Release 1.0" v1.0 


(2) 将 新 建 的 里 程 碑 推送 到 远程 共享 版 本 库 。 


$git push origin refs/tags/vi1.0 

Counting objects:1, done. 

Writing objects:100%(1/1),158 bytes, done. 
Total 1(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(1/1),done. 

To file:///path/to/repos/hello-world.git 
*[new tag]v1.0->V1.0 


到 现在 为 止 还 没有 运行 hello-world 程 序 呢 ， 现 在 就 在 开发 者 userl 
的 工作 区 中 运行 一 下 ， 具 体操 作 过 程 如 下 。 


(1) 进入 src 目 录 ， 编 译 程序 。 


$cd src 
$make 
version.h.in=>version.h 


CcCc-C-o main.o main.c 
cc-o hello main.o 


(2) 使 用 参数 --help 运 行 hello 程 序 ， 可 以 查看 帮助 信息 。 


说 明 : hello 程 序 的 帮助 输出 中 有 一 个 拼写 错误 ， 本 应 该 是 --help 的 
地 方 写成 了 -help。 这 是 有 意 为 之 。 


$./hello--help 

Hello world example v1.0 

Copyright Jiang Xin<jiangxin AT ossxp DOT com> ,2009. 
Usage: 

hello 

say hello to the world. 

hello<username> 

Say hi to the USser ， 

hello-h, -help 

this help screen. 


(3) 不 带 参 数 运行 ， 向 全 世界 问候 。 


说 明 : 最 后 一 行 显示 版 本 为 "v1.0"， 这 显然 是 来 自 于 新 建立 的 里 
程 碑 "v1.0"。 


$./hello 
Hello world. 
(version:v1.0) 


(4) 执行 命令 的 时 候 ， 后 面 添加 用 户 名 作为 参数 ， 则 向 该 用 户 问 
候 。 


说 明 : 下 面 在 运行 hello 的 时 候 ， 显 然 出 现 了 一 个 Bug， 即 用 户 名 
中 间 如 果 出 现 了 空格 ， 输 出 的 欢迎 信息 只 包含 了 部 分 的 用 户 名 。 这 个 
Bug 也 是 有 意 为 之 。 

$./hello Jiang Xin 


Hi, Jiang. 
(version:v1.0) 


既然 1.0 版 本 已 经 发 布 了 ， 现 在 是 时 候 制 订 下 一 个 版 本 2.0 的 开发 计 
划 了 。 计 划 如 下 : 


多 语种 支持 。 


为 hello-world 添 加 多 语种 文 持 ， 使 得 软件 运行 的 时 候 能 够 使 用 中 
文 或 其 他 本 地 化 语言 进行 问候 。 


用 getopt 进 行 命 令 行 解 析 。 


对 命令 行 参数 解析 框架 进行 改造 ， 以 便 实现 更 灵活 、 更 易 扩 展 的 
命令 行 处 理 。 在 1.0 版 本 中 ， 程 序 内 部 解析 命令 行 参数 使 用 了 人 简单 的 字 
符 吕 比较， 非常 不 灵活 。 从 源 文件 srcmain.c 中 可 以 看 到 当前 实现 的 简 
陋 和 局 限 。 


$git grep-n argv 

main.c:20:main(int argc,char**argv) 
main.c:24:}else if(strcmp(argv[1],"-h")==0|| 
main.c:25:strcmp(argv[1],"--help")==0)t{ 
main.c:28:printf("Hi,%s.\n",argv[1]):; 


最 终 决定 由 开发 者 user2 人 负责 多 语种 文 持 的 功能 ， 由 开发 者 userl 负 
贡 用 getopt 进 行 命令 行 解析 的 功能 。 


[1| https://github.com/ossxp-com/hello-world/ 


18.4 基于 特性 分 文 的 开发 


有 了 前 面 “ 代 码 管理 之 殊 ” 的 铺垫 ， 在 领受 任务 之 后 ， 开 发 考 user1 
和 user2 应 该 为 目 己 负责 的 功能 创建 特性 分 文 。 


18.4.1 创建 分 文 userl/getopt 


开发 者 user1 负 责 用 getopt 井 行 命令 行 解析 的 功能 ， 因 为 这 个 功能 
用 到 getopt 函 数 ， 于 是 将 这 个 分 文 俞 名 为 userl/getopt。 开 发 者 user1 使 
用 git branch 命 令 创建 该 特性 分 支 ， 具 体操 作 过 程 如 下 。 


(1) 确保 是 在 开发 者 user1 的 工作 区 中 。 


$cd/path/to/user1i/workspace/hello-world/ 


(2) 开发 者 userl 基 于 当前 HEAD 创 建 分 支 userl/getopt 。 


$git branch user1i/getopt 


(3) 使 用 git branch 创 建 分 支 ， 并 不 会 自动 切换 。 查 看 当前 分 支 可 
以 看 到 仍然 工作 在 master 分 文 (用 星 号 “*” 标 识 ) 中 。 


$git branch 
*master 
user1i/getopt 


(4) 执行 git checkout 命 令 切 换 到 新 分 文 上 。 


$git checkout user1/getopt 
Switched to branch'user1i/getopt' 


(5) 再 次 查看 分 支 列 表 ， 当 前 工作 分 文 的 标记 符 ( 星 号 ) 已 经 落 
在 userl/getopt 分 文 上 。 


$git branch 
master 
*user1i/getopt 


分 支 实 际 上 是 创建 在 目录 .git/refs/heads 下 的 引用 ， 版 本 库 初 始 时 
创建 的 master 分 支 就 是 在 该 日 录 下 。 在 第 2 篇 “第 7 章 Git 重 置 * 的 章 广 
中 ， 已 经 介绍 过 master 分 支 的 实现 ， 实 际 上 这 也 是 所 有 分 支 的 实现 方 
式 o 


查看 一 下 .git/refs/heads 目 录 下 的 引用 。 可 以 在 该 目录 下 看 到 master 
文件 ， 和 一 个 user1 目 录 。 而 在 user1 目 录 下 是 文件 getopt。 


$1]1s-F.git/refs/heads/ 
master useri1/ 
$1]1s-F.git/refs/heads/user1/ 
getopt 


引用 文件 .git/refs/heads/user1l/getopt 记 杂 的 是 一 个 提交 ID。 


$cat .git/refs/heads/user1/getopt 


ebcf6d6b06545331df156687ca2940800a3c599d 


因为 分 文 userl/getopt 是 基于 头 指针 HEAD 创 建 的 ， 因 此 当前 该 分 
文 和 master 分 文 的 指 癌 是 一 致 的 。 


$cat .git/refs/heads/master 
ebcf6d6b06545331df156687ca2940800a3c599d 


当前 的 工作 分 文 为 userl/getopt， 记 孙 在 头 指针 文件 .giVHEAD 中 。 


$cat .git/HEAD 
ref:refs/heads/user1i/getopt 


18.4.2 ”创建 分 支 user2/i18n 


开发 者 user2 要 完成 多 语种 文 持 的 工作 任务 ， 于 是 决定 将 分 文 定 名 
为 user2/i18n。 每 一 次 创建 分 支 通 第 都 需要 完成 以 下 两 个 工作 : 


创建 分 文 : 执行 git branch< branchname > 命令 创建 新 分 文 。 
切换 分 支 ， 执行 git checkout<branchname > 命令 切换 到 新 分 文 。 


有 没有 简单 的 操作 ， 在 创建 分 文 后 立即 切换 到 新 分 文 上 呢 ? 有 
的 ，Git 提 供 了 这 样 一 个 命令 ， 能 够 将 上 述 两 条 命令 所 执行 的 操作 一 次 
性 完成 * 用 半 观 下 : 


git checkout-b<new branch>[<start_point>] 


即 检 出 命令 git checkout 通 过 参数 -b < new_branch> 实现 了 创建 分 
支 和 切换 分 支 两 个 动作 的 合 二 为 一 。 下 面 开发 者 user2 束 使 用 git 
checkout 命 令 来 创建 分 支 ， 具体 操作 过 程 如 下 。 


(1) 进入 到 开发 者 user2 的 工作 目录 ， 并 和 上 游 同 步 一 次 。 


$cd/path/to/user2/workspace/hello-world/ 
$git pull 

remote:Counting objects:1,done. 
remote:Total 1i(delta 0),reused 0(delta 0) 
Unpacking objects:100%(1/1),done. 

From file:///path/to/repos/hello-world 


*[new tag]v1.0->V1.0 
Already up-to-date. 


(2) 执行 git checkout-b 命 令 ， 创 建 并 切换 到 新 分 支 user2/il8n 上 。 


$git checkout-b user2/ii8n 
Switched to a new branch 'user2/i1i8n' 


(3) 查看 本 地 分 支 列表 ， 会 看 到 已 经 创建 并 切换 到 user2/i18n 分 
6 


$git branch 
master 
*xUSer2/I18n 


18.4.3 ”开发 者 user1 完 成 功能 开发 


开发 者 user1 开 始 在 userl/getopt 分 文中 工作 ， 重 构 hello-world 中 的 
命令 行 参 数 解析 的 代码 。 重 构 时 采用 getopt_ljong 函 数 。 


您 可 以 试 着 更 改 ， 不 过 在 hello-world 中 已 经 保存 了 一 份 改 好 的 代 
码 ， 可 以 直接 检 出 。 


(1) 确保 是 在 user1 的 工作 区 中 。 


$cd/path/to/user1i/workspace/hello-world/ 


注 


(2) 执行 下 面 的 命令 ， 用 里 程 碑 jx/v2.0 标 记 的 内 容 (已 实现 用 
getopt 进 行 命令 行 解析 的 功能 ) 若 换 和 暂 存 区 和 工作 区 。 


下 面 的 git checkout 命 令 的 最 后 是 一 个 点 “<.”， 因 此 检 出 只 更 改 了 和 暂 
存 区 和 工作 区 ， 而 没有 修改 头 指针 。 


$cd/path/to/user1i/workspace/hello-world/ 
$git checkout jx/v2.0--. 


(3) 查看 状态 ， 会 看 到 分 支 仍 保持 为 userl/getopt， 但 文件 
src/main.c 被 修改 了 。 


$git status 


#0n branch user1i/getopt 
#Changes to be committed: 


#(USe "git reset HEAD<file>..." to unstage) 
## 

#modified:src/main.c 

# 


4) 比较 暂 存 区 和 HEAD 的 文件 差异 ， 可 以 看 到 为 实现 用 getopt 
进行 命令 行 解析 功能 而 对 代码 的 改动 。 


$git diff--cached 

diff--git a/src/main.c b/src/main.c 
index 6ee936f. .fa5244a 100644 
---a/sSrc/main.c 

+++b/src/main.c 

QQ@-1, 4+1, 6@@ 

#include<stdio.h> 
+#include<getopt.h> 

+ 

#include "version.h" 

int usage(int code) 

QQ@-19,15+21, 44@Q@int usage(int code) 
int 

main(int argc,char**argv) 


t 

-if(argc==1){ 

+int c; 
+char*uname=NULL:; 

十 

+while(1){ 

+int option_index=0; 
+static struct option long_options[]={ 
+{"help",0,0,'h'}, 
+{0, 0,0,0} 

+}; 


(5) 开发 者 userl 提 交代 人 码 ， 完 成 开发 任务 。 


$git commit-m "Refactor:use getopt_long for arguments parsing." 


[user1i/getopt 0881ca3]Refactor:use getopt_long for arguments 
parsing. 
1 files changed,36 insertions(+),5 deletions(-) 


(6) 提交 完成 之 后 ， 可 以 看 到 这 时 userl/getopt 分 文 和 master 分 文 
的 指向 不 同 了 。 


$git rev-parse useri/getopt master 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 
ebcf6d6b06545331df156687ca2940800a3c599d 


(7) 编译 运行 hello-world 。 


注意 输出 中 的 版 本 号 显示 


$cd src 

$make clean 

rm-f hello main.o version.h 
$make 
version.h.in=>version.h 
cCc-Cc-o main.o main.c 

cCc-o hello main.o 

$./hello 

Hello world. 
(version:v1.0-1-g0881ca3) 


18.4.4 ”将 userl/getopt 分 支 合 并 到 主线 


既然 开发 者 user1 负 责 的 功能 开发 完成 了 ， 那 束 合 并 到 开发 主线 
master 上 吧 ， 这 样 测试 团队 (如 果 有 的 话 ) 就 可 以 基于 开发 主线 master 
进行 软件 集成 和 测试 了 。 具 体操 作 过 程 如 下 。 


(1) 为 将 分 支 合并 到 主线 ， 首 先 user1 将 工作 区 切换 到 主线 ， 即 


master 分 支 。 


$git checkout master 
Switched to branch 'master' 


(2) 然后 执行 git merge 命 令 以 合并 userl/getopt 分 支 。 


$git merge user1i/getopt 

Updating ebcf6d6. .0881ca3 

Fast-forward 
src/main.c|41+++ 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 - - - - - 
1 files changed,36 insertions(+),5 deletions(-) 


(3) 本 次 合并 非常 顺利 ， 实 际 上 合并 后 master 分 文 和 userl/getopt 
指 辣 同一 个 提交 。 这 是 因为 合并 前 的 master 分 支 的 提交 就 是 usrl/getopt 
分 文 的 父 提 交 ， 所 以 此 次 合并 相当 于 将 分 文 master 重 置 到 userl/getopt 
分 文 。 


$git rev-parse USser1/getopt master 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 


0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 


(4) 查看 状态 信息 可 以 看 到 本 地 分 支 和 远程 分 支 的 跟踪 关系 。 


$git status 

#0n branch master 

#Your branch is ahead of 'origin/master' by 1 commit. 
## 

nothing to commit(working directory clean ) 


(5) 上 面 的 状态 输出 中 显示 本 地 master 分 文 比 远程 共享 版 本 库 的 
master 分 文 领 先 ， 可 以 运行 git cherry 命 令 查看 哪些 提交 领先 (未 被 推送 
到 上 游 跟踪 分 文中 ) 。 


$git cherry 
+0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 


(6) 执行 推送 操作 ， 完 成 本 地 分 支 向 远程 分 支 的 同步 。 


$git push 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(4/4),done. 
Writing objects:100%(4/4),689 bytes, done. 
Total 4(delta 3),reused 0O(delta 0) 
Unpacking objects:100%(4/4),done. 

To file:///path/to/repos/hello-world.git 
ebcf6d6. .0881ca3 master->master 


(7) 删除 userl/getopt 分 支 。 


既然 特性 分 文 userl/getopt 已 经 合并 到 主线 上 了 ， 那 么 该 分 文 已 经 
完成 了 历史 使 命 ， 可 以 放心 地 将 其 删除 。 


$git branch-d user1i/getopt 
Deleted branch useri/getopt(was 0881ca3). 


开发 者 user2 对 多 语种 支持 功能 有 些 犯 黎 ， 需 要 多 伦 些 时 间 ， 那 么 
忠 完 不 等 他 了 。 


18.5 ”基于 发 布 分 文 的 开发 
用 户 在 使 用 1.0 版 的 hello-word 过 程 中 发 现 了 两 个 错误 ， 报 告 给 项 
目 组 。 


第 一 个 问题 是 : 帮助 信息 中 出 现 文字 错误 。 本 应 该 写 为 "--help" 却 
写成 了 "-help" 总 


第 二 个 问题 是 : 当 执 行 heallo-world 的 程序 ， 提 供 带 空格 的 用 户 名 
时 ， 问 候 语 中 显示 的 是 不 完整 的 用 户 名 。 


例如 执行 "hello Jiang Xin"， 本 应 该 输出 "Hi,Jiang Xin."， 却 只 输 
出 了 "Hi,Jiang."。 


为 了 能 够 及 时 修正 1.0 版 本 中 存在 的 这 两 个 Bug， 将 这 两 个 Bug 的 
修正 工作 分 别 交 给 两 个 开发 者 user1 和 user2 完 成 : 


开发 者 user1 负 责 修 改 文字 错误 的 Bug 。 


开发 者 user2 负 责 修改 显示 用 户 名 不 完整 的 bug。 


现在 的 版 本 库 中 master 分 支 相 比 1.0 发 布 时 添加 了 新 功能 代码 ， 即 
开发 者 user1 推 送 的 用 getopt 进 行 命令 行 解析 的 相关 代码 。 如 果 基于 
master 分 文 对 用 户 报 告 的 两 个 Bug 进 行 修改 ， 束 会 引入 尚未 经 过 测试 、 


可 能 不 稳定 的 新 功能 的 代码 。 在 之 前 “代码 管理 之 殉 ” 中 介绍 的 发 布 分 
文 ， 恰 恰 适 用 于 此 场景 。 


18.5.1 创建 发 布 分 支 


要 想 解 决 在 1.0 版 本 中 发 现 的 Bug， 就 需要 基于 1.0 发 行 版 的 代码 创 
建 发 布 分 支 。 (1) 软件 hello-world 的 1.0 发 布 版 在 版 本 库 中 有 一 个 里 程 
碑 相 对 应 。 


$cd/path/to/user1i/workspace/hello-world/ 
$git tag-n1- 工 v* 
V1.0 Release 1.0 


(2) 基于 里 程 碑 v1.0 创 建 发 布 分 支 hello-1.x。 


注 : 使 用 了 git checkout 命 令 创建 分 文 ， 最 后 一 个 参数 v1.0 是 新 分 
文 hello-1.x 创 建 的 基准 点 。 如果 没 有 里 程 碑 ， 使 用 提交 ID 也 是 一 样 。 


$git checkout-b hello-1.x v1.0 
Switched to a new branch 'hello-1.x' 


(3) 用 git rev-parse 命 令 可 以 看 到 hello-1.x 分 支 对 应 的 提交 ID 和 里 
程 碑 v1.0 指 向 的 提交 一 致 ， 但 是 和 master 不 一 样 。 


提示 : 因为 里 程 碑 v1.0 是 一 个 包含 提交 说 明 的 里 程 碑 ， 因 此 为 了 
显示 其 对 应 的 提交 ID， 使 用 了 特别 的 记 法 "v1.0^{}"。 


$git rev-parse hello-1.x V1.0A{}master 

ebcf6d6b06545331df156687ca2940800a3c599d 
ebcf6d6b06545331df156687ca2940800a3c599d 
0881ca3f62ddadcddec08bd9f2f529a44d17cfbf 


(4) 开发 者 user1 将 分 文 hello-1.x 推 送 到 远程 共享 版 本 库 ， 因 为 开 
发 者 user2 修 改 Bug 时 也 要 用 到 该 分 文 。 
$git push origin hello-1.x 
Total 0(delta 0),reused 0(delta 0) 


To file:///path/to/repos/hello-world.git 
*[new branch]hello-1.x->hello-1.x 


(5) 开发 者 user2 从 远程 共享 版 本 库 获 取 新 的 分 支 。 


开发 者 user2 执 行 git fetch 命 令 ， 将 远程 共 至 版 本 库 的 新 分 文 hello- 
1.x 复 制 到 本 地 引用 origin/hello-1.xIH 上 。 
$cd/path/to/user2/workspace/hello-world/ 
$git fetch 


From file:///path/to/repos/hello-world 
*[new branch]hello-1.x->origin/hello-1.x 


(6) 开发 者 user2 切 换 到 hello-1.x 分 文 。 


本 地 引用 origin/hello-1.x 称 为 远程 分 支 ， 第 19 章 将 专题 介绍 。 该 远 
程 分 支 不 能 直接 检 出 ， 而 是 需要 基于 该 远程 分 支 创建 本 地 分 支 。 第 19 
章 会 介绍 一 个 更 为 简单 的 基于 远程 分 支 建 立 本 地 分 支 的 方法 ， 本 例 先 
用 标准 的 方法 建立 分 文 。 


$git checkout-b hello-1.x origin/hello-1.x 

Branch hello-1.x set up to track remote branch hello-1.x from 
origin. 

Switched to a new branch 'hello-1.x' 


[1] 该 引用 的 全 称 为 refs/remotes/origin/hello-1.x。 


18.5.2 ”开发 者 userl1 工 作 在 发 布 分 文 


开发 者 user1 修 改 帮助 信 息 中 的 文字 错误 ， 具 体操 作 过 程 如 下 。 
(1) 编辑 文件 srcomain.c， 将 "-help" 字 符 吕 修改 为 "--heljp" 。 


$cd/path/to/user1i/workspace/hello-world/ 
$vi src/main.c 


(2) 开发 者 user1 的 改动 可 以 从 下 面 的 差异 比较 中 看 到 。 


$git diff 

diff--git a/src/main.c b/src/main.c 
index 6ee936f..e76fO5e 100644 
---a/src/main.c 

+++b/src/main.c 

QQ-11, 7+11, 7@Q@int usage(int code) 
"say hello to the world.\n\n" 
"hello<username> \n" 

"Say hi to the user.\n\n" 
-"hello-h, -help\n" 
+"hello-h,--help\n" 

"this help screen.\n\n",_VERSION); 
return code; 


} 
(3) 执行 提交 。 


$git add-u 

$git commit-m "Fix typo:-help to--help." 
[hello-1.x b56bb51]Fix typo:-help to--help. 

1 files changed,1 insertions(+),1 deletions(-) 


(4) 推送 到 远程 共享 版 本 库 。 


$git push 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(4/4),done. 
Writing objects:100%(4/4),349 bytes, done. 
Total 4(delta 3),reused 0O(delta 0) 
Unpacking objects:100%(4/4),done. 

To file:///path/to/repos/hello-world.git 
ebcf6d6. .b56bb51 hello-1.x->hello-1.x 


18.5.3 ”开发 者 user2 工 作 在 发 布 分 文 
开发 者 user2 针 对 问候 时 用 户 名 显示 不 全 的 Bug 进 行 更 改 ， 具 体操 
作 过 程 如 下 。 
(1) 进入 开发 者 user2 的 工作 区 ， 并 确保 工作 在 hello-1.x 分 支 中 。 


$cd/path/to/user2/workspace/hello-world/ 
$git checkout hello-1.x 


(2) 编辑 文件 src/main.c， 修 改 代码 中 的 Bug 。 


$vi src/main.c 


(3) 实际 上 在 hello-world 版 本 库 中 包含 了 我 的 一 份 修改 ， 可 以 看 
看 和 您 的 更 改 是 否 一 致 。 下 面 的 命令 将 我 对 此 Bug 的 修改 保存 为 一 个 
休 丁 文件 * 


$git format-patch jx/v1.1..jx/v1.2 
0001-Bugfix-allow-spaces-in-username.patch 


(4) 应 用 我 对 此 Bug 的 改动 补丁 [1 。 


如 果 您 已 经 目 己 完成 了 修改 ， 可 以 先 执行 git stash 保 存 目 己 的 修改 
进度 ， 然 后 执行 下 面 的 命令 应 用 补丁 文件 。 当 应 用 完 补 丁 后 ， 表 执行 


git stash pop 将 您 的 改动 合并 到 工作 区 。 如 果 我 们 的 改动 一 臻 (英雄 所 
见 略 同 ) ， 将 不 会 有 冲突 。 


$patch-p1<0001-Bugfix-allow-spaces-in-username.patch 
patching file src/main.c 


(5) 看 看 代码 的 改动 吧 。 


$git diff 

diff--git a/src/main.c b/src/main.c 
index 6ee936f. .fof404b 100644 
---a/sSrc/main.c 

+++b/src/main.c 

@@-19,13+19, 20@Q@int usage(int code) 
int 

main(int argc,char**argv) 

{ 

+ 

char**p=NULL; 

十 


if(argc==1){ 

printf("Hello world.\n"); 

}else if(strcmp(argv[1],"-h")==0|| 
strcmp(argv[1],"--help")==0){ 
return usage(0); 

}elsef 
-printf("Hi,%s.\n",argv[1]):; 
+p=Sargv[1]; 

+printf("Hi,"); 

+do{ 

+printf("%s",*p); 

+jwhile( (++p)); 

+printf(".\n"); 

} 
printf("(version:%s)\n",_VERSION); 


(6) 本 地 测试 一 下 改进 后 的 软件 ， 看 看 Bug 是 否 已 经 被 改正 。 如 
果 运 行 结果 能 显示 出 完整 的 用 户 名 ， 则 Bug 成 功 修正 。 


$cd src/ 

$make 
version.h.in=>version.h 
cCc-Cc-o main.o main.c 
cCc-o hello main.o 
$./hello Jiang Xin 

Hi, Jiang Xin. 
(version:v1i.0-dirty) 


(7) 提交 代码 。 


$git add-u 

$git commit-m "Bugfix:allow Spaces in username." 
[hello-1.x e64f3a2]Bugfix:allow spaces in username. 
1 files changed,8 insertions(+),1 deletions(-) 


[1] 应 用 由 git format-patch 生 成 的 补丁 文件 ， 最 好 使 用 git am 命 令 。 这 里 
为 简单 起 见 使 用 GNU patch 命 令 。 


18.5.4 开发 者 user2 合 并 推送 


开发 者 user2 在 本 地 版 本 库 完成 提交 后 ， 不 要 走 记 同 远 程 共享 版 本 
库 进 行 推送 。 但 在 推送 分 支 hello-1.x 时 开发 者 user2 没 有 开发 者 user1 那 
么 幸运 ， 因 为 此 时 远程 共享 版 本 库 的 hello-1.x 分 支 已 经 被 开发 者 userl 


推送 过 一 次 ， 因 此 开发 者 user2 在 推送 过 程 中 会 遇 到 非 快 进 式 推送 问 
题 。 


$git push 

To file:///path/to/repos/hello-world.git 

![rejectedljhello-1.x->hello-1.x(non-fast-forward) 

error:failed to push some refs to 'file:///path/to/repos/hello- 
world.git' 

To prevent you from losing history,non-fast-forward updates were 
rejected 

Merge the remote changes(e.g.'git pull')before pushing again,See 
the 

'Note about fast-forwards' section of 'git push--help' for 
details., 


就 像 在 “第 15 章 ”Git 协 议和 工作 协同 ”一 章 中 介绍 的 那样 ， 开 发 者 
user2 需 要 执行 一 个 拉 回 操作 ， 将 远程 共享 服务 器 的 改动 获取 到 本 地 并 
和 本 地 提交 进行 合并 。 


$git pull 

remote:Counting objects:7,done. 
remote:Compressing objects:100%(4/4),done. 
remote:Total 4(delta 3),reused 0(delta 0) 
Unpacking objects:100%(4/4),done. 

From file:///path/to/repos/hello-world 
ebcf6d6. .b56bb51 hello-1.x-~>origin/hello-1.x 


Auto-merging src/main.c 

Merge made by recursive， 

src/main.c|2+- 

1 files changed,1 insertions(+),1 deletions(-) 


通过 显示 分 文 图 的 方式 查看 日 志 ， 可 以 看 到 在 执行 git pull 操 作 后 


$git 1og--graph--oneline 

*8cffe5f Merge branch 'hello-1.x' of 
file:///path/to/repos/hello-world into hello-1.x 

人 

|*b56bb51 Fix typo:-help to--help. 

*|e64f3a2 Bugfix:allow spaces in username. 

I/ 

*ebcf6d6 blank commit for GnuPG-signed tag test. 

*8a9f3d1 blank commit for annotated tag test. 

*60a2f4f blank commit. 

*3e6070e Show version. 

*75346b3 Hello world initialized. 


现在 开发 者 user2 可 以 将 合并 后 的 本 地 版 本 库 中 的 提交 推送 给 远程 
共 至 版 本 库 了 。 


$git push 

Counting objects:14,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(8/8),done. 
Writing objects:100%(8/8),814 bytes, done. 
Total 8(delta 6),reused 0O(delta 0) 
Unpacking objects:100%(8/8),done. 

To file:///path/to/repos/hello-world.git 
b56bb51..8cffesSf hello-1.x->hello-1.x 


18.55 发 布 分 文 有 网民 交 合计 下 生生 


当 开 发 者 user1 和 user2 都 相继 在 hello-1.x 分 支 中 将 相应 的 Bug 修 改 
完 后 ， 束 可 以 从 hello-1.x 分 文中 编译 新 的 软件 产品 交 给 客户 使 用 了 。 
接 下 来 别 筷 了 在 主线 master 分 文中 也 做 出 同样 的 更 改 ， 因 为 在 hello-1.x 
分 文中 修改 的 Bug 同 样 也 存在 于 主线 master 分 文中 。 


1. 拣 选 操作 


使 用 Git 提 供 的 拣选 命令 ， 束 可 以 直接 将 发 布 分 文 上 进行 的 Bug 修 
正 合 并 到 主线 上 。 下 面 就 以 开发 者 user2 的 身份 进行 操作 ， 具 体操 作 过 
程 如 下 。 


(1) 进入 user2 工 作 区 并 切换 到 master 分 支 。 


$cd/path/to/user2/workspace/hello-world/ 
$git checkout master 


(2) 从 远程 共享 版 本 库 同 步 master 分 支 。 


同步 后 本 地 master 分 支 包含 了 开发 者 user1l 提 交 的 命令 行 参数 解析 
重 构 的 代码 。 
$git pull 


remote:Counting objects:7,done. 
remote:Compressing objects:100%(4/4),done. 


remote:Total 4(delta 3),reused 0(delta 0) 

Unpacking objects:100%(4/4),done. 

From file:///path/to/repos/hello-world 

ebcf6d6. .0881ca3 master->origin/master 

Updating ebcf6d6. .0881ca3 

Fast-forward 
src/main.c|41++ 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 -~ - - - 
1 files changed,36 insertions(+),5 deletions(-) 


(3) 查看 分 文 hello-1.x 的 日 志 ， 确 认 要 拣选 的 提交 ID 。 


从 下 面 的 日 志 中 可 以 看 出 分 文 hello-1.x 的 最 新 提交 是 一 个 合并 提 
区 ， 而 要 拣选 的 提交 分 别 是 其 第 一 个 父 提 交 和 第 二 个 父 提 区 ， 可 以 分 
别 用 "hello-1.xA1" 和 "hello-1.xA2" 表 示 。 


$git lo0g-3--graph--oneline hello-1.x 

*8cffe5f Merge branch 'hello-1.x' of 
file:///path/to/repos/hello-world into 

hello-1.x 

| 

|*b56bb51 Fix typo:-help to--help. 

*|e64f3a2 Bugfix:allow spaces in username. 

I/ 


(4) 执行 拣选 操作 。 先 将 开发 者 user2 提 交 的 修正 代码 拣选 到 当 
前 分 支 〈 即 主线 ) 。 


拣选 操作 过 到 了 神 突 ， 见 下 面 的 命令 输出 。 


$git cherry-pick hello-1.x^1 

Automatic cherry-pick failed.After resolving the conflicts, 

mark the corrected paths with 'git add<paths>"' or 'git rm< 
paths> 

and commit the result with : 

git commit-c e64f3a216d346669b85807ffcfb23a21f9c5c187 


(5) 拣选 操作 发 生 冲 突 ， 通 过 查看 状态 可 以 看 到 是 在 文件 
src/main.c 上 发 生 了 冲突 。 


$git status 
#0n branch master 
#Unmerged paths: 


#(USe "git reset HEAD<file>..." to unstage) 

#(USe "git add/rm<file>..." as appropriate to mark resolution) 
# 

#both modified:src/main.c 

# 


no changes added to commit(use "git add" and/or "git commit-a") 


2. 冲 突 发 生 的 原因 


为 什么 发 生 了 神 突 昵 ? 这 是 因为 拣选 hello-1.x 分 文 上 的 一 个 提交 
到 master 分 文 时 ， 因 为 两 个 甚至 多 个 提交 在 重 有 到 的 位 置 更 改 代码 所 
致 。 通 过 下 面 的 命令 可 以 看 到 到 撒 是 哪些 提交 引起 的 冲突 。 


$git log master...hello-1.x^1 

commit e64f3a216d346669b85807ffcfb23a21f9c5c187 

Author:user2<user2@moon.ossxp.com> 

Date:Sun Jan 9 13:11:19 2011+0800 

Bugfix:allow spaces in username. 

commit 0881ca3f62ddadcddec08bd9f2f529a44d17cfbf Author:user1< 
user1iQ@sun.ossxp.com> 

Date:Mon Jan 3 22:44:52 2011+0800 

Refactor:use getopt_long for arguments parsing. 


可 以 看 出 引发 冲突 的 提交 一 个 是 当前 工作 分 文 master 上 的 最 新 所 
克 ， 即 开发 者 user1 的 重 构 命令 行 参数 解析 的 提交 ， 而 男 外 一 个 引发 促 
突 的 是 要 拣选 的 提交 ， 即 开发 者 user2 针 对 用 户 名 显示 不 全 所 做 的 错误 


修正 提交 。 一 定 是 因为 这 两 个 提交 的 更 改 发 生 了 重 受 导致 了 冲突 的 发 
生 。 下 面 瑟 来 解决 冲突 。 


3. 冲 突 解 决 


冲突 解决 可 以 使 用 图 形 界面 工具 ， 不 过 对 于 本 例 直 接 编辑 冲突 文 
件 ， 手 工 进行 冲突 解决 也 很 方便 。 打 开 文 件 src/main.c 束 可 以 看 到 发 生 
冲突 的 区 域 都 用 特有 的 标记 符 标 识 出 来 ， 参 见 表 18-1 中 左 侧 一 列 的 内 


di 


= 


表 18-1 冲突 解决 前 后 对 照 


训 突 文件 srcimain.c 标识 出 的 冲突 内 容 


21 nt 

22 main{int argc, char **argy) 

231 

24 <<<<<<< HEAD 

25 inte; 

26 char*uname = NULL:; 

学 

28 while{l)! 

29 int option index = 0; 

30 static struct option long options[|] = | 
31 {"help", 0, 0, hb， 

32 40, 0, 0, 0} 

33 3 

34 

35 c= gctopt longfargc. argv "h", 
36 long options, &option index); 
37 iffc 一 一 号 

38 break: 

39 

40 Switch (c) { 

#1 case 'h": 

42 return usage{0); 

二 3 default: 

下 return usage( 1); 

45 } 

46 |} 

47 


48 if {optind < argc) + 
9 uname = argy[optind]; 


> 

51 

2 ifuname 一 NULL) 1 
53 一 = 一 一 

54 char**p= NULL; 

55 


56 if{argc== 1)1 
57 >>>>>>> edf3a2... Bugtix: allow spaces in username. 
58 printf (“Hello world.\n™): 


59 }else{ 

60 <<<<<<< HEAD 

61 printf (“Hi, %s. Win", uname); 
62 ====== 


63 p= &argv[1); 
64 printf (“Hi,"); 


65 do 
66 printf (" %s", *p); 
67 } while {*(++p)); 


68 printf (™. Mn"); 
69 >>>>>>> e6413a2... Bugfix: allow spaccs in uscermame. 
wo 3} 


72 printft "(version: %sjin", VERSION ); 
713 return 0; 


冲突 解决 后 的 内 容 对 昭 
21 int 
22 main(int argc, char **argv) 
2 
24 intc; 
25 char**p= NULL; 
26 
27 while (1) 
28 int option index = 省 
29 static struct option Iong_optionsf] = | 
30 f"hcilp", 0, 0, ‘h'}, 
31 {0, 0. 0, 0} 
32 六 
33 
34 c= getopt long(argc, argv, “h", 
35 long options, &option index); 
36 iffc == -1) 
37 break; 
38 
39 Switch (c) 1 
40 casc 'h': 
41 return usagel 0); 
4 default: 
43 return Usagcl 1); 


44 ! 

45 } 

46 

47 floptind < argc) ! 

48 p= &argv[optind]; 

d49 } 

50 

51 if(p=NULLI*p = NULL)! 


| printf{"Hello world \n"); 
53 Jelset 


54 printf ("Hi,"); 

$5 do ; 

56 printf (™ %s", *p); 
$7 } while (*(++p)); 
58 printf {".\n"); 


59  } 

60 

61 printfi "(yersion: %sjin"，VERSION ); 
62 return 0: 

63 } 


在 文件 src/main.c 冲 突 内 容 中 ， 第 25-52 行 及 第 61 行 是 master 分 文中 
由 开发 者 user1 重 构 命 令 行 解析 时 提交 的 内 容 ， 而 第 54~~56 行 及 第 63-68 
行 则 是 分 支 hello-1.x 中 由 开发 者 user2 提 交 的 修正 用 户 名 显示 不 全 的 Bug 
的 相应 代码 。 

表 18-1 右 侧 的 一 列 则 是 冲突 解决 后 的 内 容 。 为 了 和 冲突 前 的 内 容 
相对 照 ， 重 新 进行 了 排版 ， 并 对 差异 内 容 进 行 加 粗 显 示 。 您 可 以 参照 
完成 冲突 解决 。 


将 手动 编辑 完成 的 文件 src/main.c 添 加 到 和 暂 存 区 才 真 正 地 完成 了 冲 
突 解决 。 


$git add src/main.c 


因为 是 拣选 操作 ， 提 区 时 最 好 重用 所 拣选 提交 的 提交 说 明和 作者 
信息 ， 而 且 也 省 下 了 上 自己 写 提 交 说 明 的 碳 烦 。 使 用 下 面 的 命令 完成 提 
交 操 作 。 
$git commit-C hello-1.x^1 


[master 10765a7]Bugfix:allow spaces in username. 
1 files changed,8 insertions(+),4 deletions(-) 


4. 完 成 全 部 拣选 操作 


接 下 来 再 将 开发 着 user1 在 分 文 hello-1.x 中 的 提交 也 拣选 到 当前 分 


文 。 所 拣选 的 提交 非常 簿 单 ， 不 过 是 修改 了 提交 说 明 中 的 文字 错误 而 
已 ， 拣 选 操作 也 不 会 引发 异常 ， 直 接 完 成 。 


入 


$git cherry-pick hello-1.x^2 

Finished one cherry-pick. 

[master d81i896e]Fix typo:-help to--help. 
Author:user1<user1iQ@sun.ossxp.com> 

1 files changed,1 insertions(+),1 deletions(-) 


现在 通过 日 志 可 以 看 到 master 分 文 已 经 完成 了 对 已 知 Bug 的 修复 。 


$git 1og-3--graph--oneline 

*d81896e Fix typo:-help to--help. 

*10765a7 Bugfix:allow spaces in username. 

*0881ca3 Refactor:use getopt_long for arguments parsing. 


查看 状态 可 以 看 到 当前 的 工作 分 支 相对 于 远程 服务 器 有 两 个 新 所 


$git status 

#0n branch master 

#Your branch is ahead of 'origin/master' by 2 commits. 
# 

nothing to commit(working directory clean) 


执行 推送 命令 将 本 地 master 分 文 同 步 到 远程 共享 版 本 库 。 


$git push 

Counting objects:11, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(8/8),done. 
Writing objects:100%(8/8),802 bytes, done. 


Total 8(delta 6),reused 0O(delta 0) 
Unpacking objects:100%(8/8),done. 

To file:///path/to/repos/hello-world.git 
0881ca3..d81896e master->master 


18.6 ”分支 变 基 


18.6.1 完成 user2/i18n 特 性 分 支 的 开发 


二 
日 


开发 者 user2 针 对 多 语种 开发 的 工作 任务 还 没有 介绍 呢 ， 在 最 后 束 
着 “实现 ”这 个 稍微 复杂 的 功能 来 学 习 一 下 Git 分 文 的 变 基 操作 ， 具 体 


操作 过 程 如 下 。 


合 巴 
有 


(1) 进入 user2 的 工作 区 ， 并 切换 到 user2/i18n 分 支 。 


$cd/path/to/user2/workspace/hello-world/ 
$git checkout user2/il1i8n 
Switched to branch 'user2/i1i8n' 


(2) 使 用 gettext 为 软件 添加 多 语言 支持 。 您 可 以 尝试 实现 该 功 
* 不 过 在 hello-world 中 已 经 保存 了 一 份 实现 该 功能 的 代码 ( 见 里 程 


人 碑 jx/v1.0-i18n) ， 可 以 直接 拿 过 来 用 。 


(3) 里 程 牧 jx/v1.0-il8n 最 后 的 两 个 提交 实现 了 多 语言 文 持 功 能 。 


$git log--oneline-2--stat jx/v1.0-ii8n 

ade873c Translate for Chinese. 
src/locale/zh_CN/LC_MESSAGES/helloworld.po|30++++++ 十 十 十 十 十 十 十 十 十 十 十 十 十 
1 files changed,23 insertions(+),7 deletions(-) 

0831248 Add I18N support. 

SrC/Makefi]e | 21++ 十 十 十 十 十 十 十 十 十 - 
Src/Locale/vhel1lowor1d .pot |46+++ 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 


Src/locale/zh_CN/VLC_MESSAGESVhe1L]lowor1d .po | 46++++ 十 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
十 十 十 十 十 十 十 十 十 


src/main.c|18++++++++-- 
4 files changed,125 insertions(+),6 deletions(-) 


(4) 可 以 通过 拣选 命令 将 这 两 个 提交 拣选 到 user2/i18n 分 文中 ， 
相当 于 在 分 支 user2/i18n 中 实现 了 多 语言 支持 的 开发 。 


$git cherry-pick jx/v1.0-ii8n~1 


$git cherry-pick jx/v1.0-ii8n 


(5) 看 看 当前 分 支 拒 选 后 的 日 志 。 


$git 1og--oneline-2 
7acb3e8 Translate for Chinese.90d873b Add I18N support. 


(6) 为 了 测试 刚刚 “开发 "完成 的 多 语言 支持 功能 ， 先 对 源码 执行 


编译 。 


$cd src 

$make 

version.h.in=>version.h 

cCc-Cc-o main.o main.c 

msgfmt-o locale/zh_CN/LC_MESSAGES/helloworld.mo 
locale/zh_CN/LC_ MESSAGES/helloworld.po 

cCc-o hello main.o 


(7) 查看 帮助 信息 ， 会 发 现 帮助 信息 已 经 本 地 化 。 


主意 : 帮助 信息 中 仍然 有 文字 错误 ，--help 误 写 为 -heljp。 


$./hello--help 

Hello world 示 例 v1.0-2-g7acb3e8 

版 权 所 有 蒋 诸 < jiangxin AT ossxp DOT com> ,2009 
3 法: 

hello 

界 你 好 。 

hello<username> 

可 用 户 问 您 好 。 

hello-h, -help 

显示 本 帮助 页 。 


[EE 


(8) 不 带 用 户 名 运行 hello， 也 会 输出 中 文 。 


$./hello 
世界 你 好 。 
(version:v1.0-2-g7acb3e8) 


(9) 带 用 户 名 运行 hello， 会 向 用 户 问 候 。 


注意 : 程序 仍然 存在 只 显示 部 分 用 户 名 的 问题 。 


$./hello Jiang Xin 
您 好 ,Jiang ， 
(version:v1.0-2-g7acb3e8) 


(10) 推送 分 支 user2/i18n 到 远程 共享 服务 器 。 


推送 该 特性 分 文 的 目的 并 非 是 与 他 人 在 此 分 文 上 协同 工作 ， 主 要 
征 为 了 进行 数据 备份 。 


$git push origin user2/i18n 

Counting objects:21, done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(13/13),done. 


Writing objects:100%(17/17),2.91 KiB, done. 
Total 17(delta 6),reused 1(delta 0) 
Unpacking objects:100%(17/17), done. 

To file:///path/to/repos/hello-world.git 
*[new branch]user2/i1i8n->user2/ii8n 


18.6.2 分支 user2/i18n 变 基 


在 测试 刚刚 完成 的 具有 多 语种 支持 功能 的 nel1o-wor1a 时 ， 之 前 改正 的 两 个 Bug 又 
重 现 了 。 这 并 不 闸 任 ， 因 为 分 支 user2/il8n 基于 master 分 支 创建 的 时 候 ， 这 两 个 Bug 
还 没有 发 现 呢 ， 更 不 要 说 改正 了 . 

在 最 旺 刚 刚 创建 User2/il8n 分 支 时 ， 版 本 库 的 结构 非常 简单 ， 如 图 18-6 所 示 ， 


18-6 分支 user2/ilgn 创建 初始 版 本 库 的 分 支 状态 


但 是 当前 master 分 支 中 不 但 包含 了 对 两 个 Bug 的 修正 ， 还 包含 了 开发 者 userl 调 
用 getopt 对 命令 行 参数 解析 进行 的 代码 重 构 。 图 18-7 显示 的 是 当前 版 本 库 master 分 支 和 
user2/il8n 分 支 的 关系 图 ， 


nee ne 
{ moo 人 § bugix#2 } 
Wa Woes We 


PT 


图 18-7 当前 版 本 库 分 支 示意 图 


开发 者 user2 要 将 分 支 user2/il8n 中 的 提交 合并 到 主线 mastezr 中 ， 可 以 采用 上 一 
节 介 绍 的 分 支 合并 操作 。 如 果 执 行 分 支 合并 操作 ， 版 本 库 的 状态 将 会 如 图 18-8 所 示 : 


18-8 ”使 用 分 支 合 并 时 版 本 库 的 分 支 状态 


这 样 操 作 有 利 有 整 。 有 利 的 一 面 是 开发 者 在 user27il18n 分 支 中 的 提交 不 会 发 生 改 变 ， 
这 一 点 对 于 提交 已 经 被 他 人 共享 时 很 重要 。 再 有 因为 user2/il8n 分 支 是 基于 v1.-0 创建 
的 ， 这 样 可 以 很 容易 将 多 语言 支持 功能 添加 到 1.0 版 本 的 hello-worl1d 中 。 不 过 这 些 对 于 
本 项 目 来 说 都 不 重要 。 至 于 不 利 的 一 面 ， 就 是 这 样 的 合并 操作 会 产生 三 个 提交 包括 一 个 合 
并 提交 )， 对 于 要 对 提交 进行 审核 的 项 目 团队 来 说 增加 了 代码 审核 的 负担 。 因 此 很 多 项 目 在 
特性 分 支 合并 到 开发 主线 的 时 候 ， 都 不 推荐 使 用 合并 操作 ， 而 是 使 用 变 基 操 作 。 如 果 执 行 变 
基 操 作 ， 版 本 库 相 关 分 支 的 关系 图 就 如 图 18-9 所 示 ， 


图 18-9 ”使 用 变 基 操作 版 本 库 的 分 支 状态 


很 显然 ， 采 用 变 基 操 作 的 分 文 天 系 图 要 比 采 用 合并 操作 的 简单 多 
了 ， 看 起 来 更 像 旦 集中 式 版 本 控制 系统 竺 有 的 顺序 提交 。 因 为 减少 了 
一 个 提交 ， 也 会 减轻 代码 审核 的 负担 。 


下 面 开 发 者 user2 束 通过 变 基 操作 将 特性 分 文 user2/il18n 合 并 到 主 
线 ， 有 具体 操作 过 程 如 下 。 


(1) 首先 确保 开发 者 user2 的 工作 区 位 于 分 文 user2/il8n 上 。 


$cd/path/to/user2/workspace/hello-world/ 
$git checkout user2/ii8n 


(2) 执行 变 基 操作 。 


$git rebase master 

First,rewinding head to replay your work on top of it... 

Applying:Add I18N support. 

Using index info to reconstruct a base tree... 

Falling back to patching base and 3-way merge... 

Auto-merging src/main.c 

CONFLICT(content):Merge conflict in src/main.c 

Failed to merge in the changes. 

Patch failed at 0001 Add I18N support. 

When you have resolved this problem run "git rebase--continue'"， 

If you would prefer to Skip this patch,instead run "git rebase-- 
skip". 

To restore the original branch and stop rebasing run "git 
rebase--abort". 


变 基 遇 到 了 神 突 ， 看 来 这 回 的 麻烦 可 不 小 。 神 突 是 在 合并 
user2/i18n 分 支 中 的 提交 "Add I18N support" 时 过 到 的 。 首 先 回顾 一 下 变 
基 的 原理 ， 参 见 第 2 篇 “第 12 章 改变 历史 ”的 相关 章节 。 对 于 本 例 ， 在 进 


行 变 基 操作 时 会 移 切 换 到 user2/il8n 分 文 ， 并 强制 重 置 到 master 分 文 所 
指向 的 提交 。 然 后 再 将 原 user2/il8n 分 支 的 提交 一 一 拣选 到 新 的 
user2/i18n 分 支 上 。 运 行 下 面 的 命令 可 以 查看 可 能 导致 冲突 的 提交 列 
表 o 

$git rev-list--pretty=oneline user2/i1i8n^,..master 

d81896e60673771ef1873b27a33f52df75f70515 Fix typo:-help to-- 
help. 

10765a7ef46981a73d578466669f6e17b73ac7e3 Bugfix:allow spaces in 
username. 

90d873bb93cd7577b7638f1f391bd2ece3141b7a Add I18N support. 

0881ca3f62ddadcddec08bd9f2f529a44d17cfbf Refactor:use 


getopt_long for arguments 
parsing 


刚刚 发 生 的 冲突 是 在 拣选 提交 "Add I18N suppport" 时 出 现 的 ， 所 
以 在 冲突 文件 中 标识 为 他 人 版 本 的 是 user2 添 加 多 语种 支持 功能 的 提 
交 ， 而 神 突 文件 中 标识 为 自己 版 本 的 是 修正 两 个 Bug 的 提交 及 开发 者 
userl 提 交 的 重 构 命令 行 参数 解析 的 提交 。 下 面 的 两 个 表格 ( 表 18-2 和 
表 18-3) 是 文件 src/main.c 发 生 冲 突 的 两 个 主要 区 域 ， 表 格 的 左 侧 一 列 
是 冲突 文件 中 的 内 容 ， 右 侧 一 列 则 是 冲突 解决 后 的 内 容 。 为 了 方便 对 
照 进行 了 适当 排版 。 


表 18-2 变 基 冲突 区 域 一 解决 前 后 对 照 


变 其 冲突 区 域 一 内 容 〈 文 件 srcimain.c》 


12 int usage(int codc) 


131 

14 printft (“Hello world example %s\n" 

15 "Copyright Jiang Xin <jiangxin AT ossxp ...\n" 
16 Wn” 

17 "Usage:m” 

18 ” hellown" 

19 say hello to the world.nn” 

20 "hello <username>n” 

21 人 Say hi to the user. nin" 

22 <<<<<<< HEAD 

23 ” hello -h, --help\n" 

24 y this help sereen n\n", VERSION); 


25 I merged common ancestors 
26 ” hello -h, -help\n™ 


溃 突 解决 后 竟 内容 对 照 


12 int usage(int code) 


| 

14 Printff ("Hello world example %s\in" 

15 "Copyright Jiang Xin <jiangxin AT ossxp ...\n" 
16 "nn" 

17 "Usage:\n" 

18 ”hello\n" 

19 say hello to the world.‘n\in" 

20 ” hecllo <username>"n" 

21 外 say hi to the uscr ‘nin" 

22 ” hello -h, --help\n" 

23 9 this help sereen.\n\n"), VERSION): 


27 this help secreen. nin", VERSION). 
28 =—====== 
29 "hello -h, -helpin” 


30 和 this hclp sercen. n\n"), VERSION); 
31 >>>>>>> Add I18N support. 

32 return codc; 

33 ) 


24 return code: 
23: 


表 18-3 变 基 冲突 区 域 二 解决 前 后 对 照 


变 项 冲突 区 域 二 内 容 (文件 srelmain.c) 
38 <<<<<<< HEAD 


39 inte; 
40 char**p= NULL; 
41 


冲突 解决 后 的 内 容 对 照 


int ci 
char **p = NULL: 


setlocale( LC ALL,™" ): 
bindtextdomain("helloworld", "locale"):; 
textdomain("helloworld"): 


42 while(l)! while (1) { 

43 int option index = 0; int option index = 

了 static struct option long options[]= ! static struct option long options[] = | 
45 {"help", 0, 0, hb 个， "hclp", 0, 0, 中， 

46 10. 0, 0.0} {0, 0, 0, 0} 

47 }; 牛 

48 

49 c= gctopt_longfargc. argv, "h", c= getopt long(argc, argv, "h", 
50 long_ options, &option indcx); long_options, &option index); 
5 if(c==—1) 让 fc ==—1) 

52 break:; brcak 

53 

54 Switch (c) { Switch (c) { 

55 case 'h'; case 'h'- 

56 retum usage(0); return usagcel 0); 

57 default: default: 


变 莫 冲突 区 域 二 内 容 (文件 sreimain.c，》 


58 return usage{ 1); 

59 } 

60 |} 

61 

62 if(optind <argc) 1 

63 p= &Kargv[optind]; 

A: 

65 

66 if{p== NULLI *p== NULL)! 
67 Printf ("Hello world\n"); 

68 | merged common ancestors 

69 if{argc == 1){ 

70 printf (~Hello world.\n™); 

71 } elscif( strcmp(argv{[1],"-h")== 0 | 


72 stremp{argvy{1],"--help") == 0)1 
3 return usage(0); 
74 == 一 == 


7$ sctlocale{ LC ALL,""); 

76 bindtextdomain("helloworld", "locale"); 
37 textdomain("helloworld"); 

78 

79 if(argc == 1)!} 

80 printf( 人"Hello world,\n") ): 

Sl elseiff stremp(arev[1],"-h") ==0|| 


82 strcmpfargv[I],"--help == 0) 1 
83 return usage(0); 

84 >>>>>>> Add Ll8N support. 

85 }celse{ 


86 <<<<<<< HEAD 

87 printf ("Hi,"): 

S38 doi 

89 printf (" %s", *p); 
90 } while (*(++p)); 

91 printf (™.\n"); 


92 | merged common ancestors 
93 printf (“Hi, %s.\n", argv[1]); 
94 = 一 一 


95 printf (_("Hi, %s.\n"), argy[1]); 
96 >>>>>>> Add [18N support. 
97 3 


63 


全 


60 
67 
68 


69 


( 统 ) 
训 突 解决 后 的 内 容 对 照 


return usagel 1]); 
1 


if (optind < argc) | 
p = &argv[optind]:; 
} 


if (p= NULLI*p = NULL)!: 
printf{ _("Hello world\n") 上 


printf{_ ("Hi,")); 
do ! 

printf (™ %s", *p); 
上 while (*{++p)); 
printf ("\n"); 


将 完成 冲突 解决 的 文件 srcmain.c 加 入 暂 存 区 。 


$git add-u 


查看 工作 区 状态 。 


$git status 
#Not currently on any branch. 
#Changes to be committed: 


# (use "git reset HERD <file>,.." to nstage' 

站 

提 modified: src/Makefile 

提 new file: src/locale/helloworld.pot 

检 new file: src/locale/zh CN/LC MESSAGES/helloworld.po 
## modified: src/main.c 

打 


现在 不 要 执行 提交 ， 而 是 继续 变 基 操作 。 变 基 操 作 会 自动 完成 对 冲突 解决 的 提交 ， 并 对 
分 支 中 的 其 他 提交 继续 执行 变 基 ， 直 至 全 部 完成 


S git rebase ~~cContinue 
Applying: Add I18N support. 
Mpplying: Translate for Chinese. 


图 18-10 显示 了 版 本 库 执行 完 变 基 后 的 状态 ， 


On EE 
Ue We 


图 18-10 变 基 操作 完成 后 版 本 庄 的 分 支 状态 


现在 需要 将 user2yil8n 分 支 的 提交 合并 到 主线 master 中 。 实 际 上 不 需要 在 
master 分 支 上 再 执 行 繁琐 的 合并 操作 ， 而 是 可 以 直接 用 推送 操作 一 一 用 本 地 的 user2/ 
i18n 分 支 直接 更 新 远程 版 本 库 的 master 分 支 。 


$ git push origin user2/ilgn:master 

Counting objects: 21, done, 

Delta compression using up to 2 threads, 
Compressing obiects: 100% {13/13)}, done. 
Writing obiects: 100% (17/17), 2.91 KiB, done 
Total 17 {delta 6}, reused 1 (delta 0)， 
Unpacking cbiects: 100% (17/17}, done. 

To file:///path/to/repos/hello-world.qit 


仔细 看 看 上 面 运行 的 git push 命 令 ， 终 于 看 到 了 引用 表达 式 中 冒号 
前 后 使 用 了 不 同名 字 的 引用 。 含 义 是 用 本 地 的 user2/il8n 引 用 的 内 容 
(提交 ID) 更 新 远程 共享 版 本 库 的 master 引 用 内 容 (提交 ID) 。 


执行 拉 回 操作 ， 可 以 发 现 远 程 共享 版 本 库 的 master 分 文 的 确 被 更 
渐 了 。 通 过 拉 回 操作 本 地 的 master 分 文 也 随 之 更 新 。 


(1) 切换 到 master 分 支 ， 会 从 提示 信息 中 看 到 本 地 master 分 支 落 
后 远程 共享 版 本 库 master 分 文 两 个 提交 


$git checkout master 

Switched to branch 'master' 

Your branch is behind 'origin/master' by 2 commits,and can be 
fast-forwarded. 


(2) 执行 拉 回 操作 ， 将 本 地 master 分 文 同步 到 和 远程 共享 版 本 库 
相同 的 状态 让 


$git pull 

Updating d81896e..c4acab2 

Fast-forward 

src/Makefile|21++++++++- 

src/locale/helloworld.pot|46+++++ 二 十 十 十 十 十 十 十 十 十 十 十 十 十 十 

src/locale/zh_CN/LC_MESSAGES/helloworld.po|62+++++ 十 十 十 十 十 十 十 十 十 十 十 十 十 十 
十 十 十 十 十 十 十 十 十 

src/main.c|18++++++-- 

4 files changed,141 insertions(+),6 deletions(-) 

create mode 100644 src/locale/helloworld.pot 

create mode 100644 src/locale/zh_CN/LC_MESSAGES/helloworld.po 


特性 分 文 user2/i18n 也 完成 了 历史 使 傅 ， 可 以 删除 了 。 因 为 之 前 
user2/il18n 已 经 推送 到 远程 共享 版 本 库 ， 如 果 想 要 删除 分 文 不 要 环 了 也 
将 远程 分 支 同 时 删除 。 


(1) 删除 本 地 版 本 库 的 user2/i18n 分 支 。 


$git branch-d user2/ii8n 
Deleted branch user2/i1i8n(was c4acab2). 


(2) 删除 远程 共享 版 本 库 的 user2/i18n 分 支 。 


$git push origin:user2/i1i8n 
To file:///path/to/repos/hello-world.git 
-[deleted]juser2/i1i8n 


补充 实际 上 变 基 之 后 user2/i18n 分 支 的 本 地 化 模板 文件 
(helloworld.pot) 和 汉化 文件 (helloworld.po) 都 需要 做 出 相应 更 新 ， 
否则 hello-world 的 一 些 输出 不 能 进行 本 地 化 。 更 新 模板 需要 删除 文件 
helloworld.pot， 再 执行 命令 make po。 重 新 翻译 中 文本 地 化 文件 ， 可 以 
使 用 工具 lokalize 或 kbabel。 具 体 的 操作 过 程 就 不 再 葡 述 了 。 


[在 本 篇 第 20 章 "20.3.1 StGit" 一 万 会 弥补 这 一 和 遗憾， 完善 Hello Word 
的 本 地 化 。 


第 19 章 ”远程 版 本 库 


Git 作 为 分 布 式 版 本 库 控制 系统 ， 每 个 人 都 是 本 地 版 本 库 的 主人 ， 
可 以 在 本 地 的 版 本 库 中 随心 所 欲 地 创建 分 文 和 里 程 碑 。 当 需要 多 人 协 
作 时 ， 问 题 就 出 现 了 : 


如 何 避 人 免 因 为 用 户 把 所 有 的 本 地 分 支 都 推送 到 共享 版 本 库 ， 从 而 
造成 共 至 版 本 库 上 分 支 的 混乱 ? 


如 何 避 免 不 同 用 户 针对 不 同 特性 开发 创建 了 相同 名 字 的 分 文 而 造 
成 分 文 名 称 的 冲突 ? 


如 何 避 免 用 户 随 意 在 共 至 版 本 库 中 创建 里 程 碑 而 导致 里 程 碑 名 称 
上 的 混乱 和 冲突 ? 


当 用 户 同 共 至 版 本 库 及 其 他 版 本 库 推 送 时 ， 每 次 部 需要 输入 长 长 
的 版 本 库 URL， 太 不 方便 了 。 


当 用 户 需 要 经 党 从 多 个 不 同 的 他 人 版 本 库 中 获取 提交 时 ， 有 没有 
办 法 不 要 总 是 输入 长 长 的 版 本 库 URL? 


如 果 不 囊 任何 其 他 参数 执行 git fetch、git pull 和 git push 到 撒 是 和 哪 
个 远程 版 本 库 及 哪个 分 文 进行 交互 ? 


本 章 介 绍 的 git remote 命 令 就 是 用 于 实现 对 远程 版 本 库 的 便捷 访 
问 ， 建 立 远程 分 文 和 本 地 分 文 的 对 应 ， 使 得 git fetch、git pull 和 git push 
能 够 更 为 便捷 地 进行 操作 。 


19.1 远程 分 文 


上 一 章 介 绍 Git 分 文 的 时 候 ， 每 一 个 版 本 库 最 多 只 和 一 个 上 游 版 本 
车 (远程 共享 版 本 库 ) 进行 交互 ， 实 际 上 Git 允 许 一 个 版 本 库 和 任意 多 
的 版 本 库 进 行 交互 。 首 先 执行 下 面 的 命令 ， 基 于 hello-world.git 版 本 库 
再 创建 几 个 新 的 版 本 库 。 


$cd/path/to/repos/ 

$git clone--bare hello-world.git hello-user1.git 
Cloning into bare repository hello-user1.git... 
done. 

$git clone--bare hello-world.git hello-user2.git 
Cloning into bare repository hello-user2.git... 
done ， 


现在 有 了 三 个 共享 版 本 库 : hello-world.git、hello-user1.git 和 hello- 
user2.git。 现 在 有 一 个 疑问 ， 如 果 一 个 本 地 版 本 库 需 要 和 上 面 三 个 版 本 


库 进行 互 操作 ， 三 个 共享 版 本 库 都 存在 一 个 master 分 文 ， 会 不 会 互相 
干扰 、 冲 突 或 覆盖 呢 ? 


完 来 看 看 hello-world 远 程 共 享 版 本 库 中 包含 的 分 文 有 哪些 : 


$git ls-remote--heads file:///path/to/repos/hello-world.git 


8cffe5f135821e716117ee59bdd53139473bd1d8 refs/heads/hello-1.x 

bb4fef88fee435bfac04b8389cf193d9c04105a6 
refs/heads/helper/master 

cf71ae3515e36a59c7f98b9db825fdof2a318350 refs/heads/helper/vi.x 

c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/heads/master 


原来 远程 共享 版 本 库 中 有 四 个 分 支 ， 其 中 hello-1.x 分 支 是 开发 者 
user1 创 建 的 。 现 在 重新 克隆 该 版 本 库 ， 如 下 : 


$cd/path/to/my/workspace/ 
$git clone file:///path/to/repos/hello-world.git 


$cd/path/to/my/workspace/hello-world 


执行 git branch 命 令 检 查分 支 ， 会 吃惊 地 看 到 只 有 一 个 分 文 


master ° 


$git branch 
*master 


那么 远程 版 本 库 中 的 其 他 分 支 哪 里 去 了 ? 为 什么 本 地 只 有 一 个 分 
支 呢 ?执行 git show-ref 命 令 可 以 看 到 全 部 的 本 地 3 引用。 


$git show-ref 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 refs/heads/master 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 
refs/remotes/origin/HEAD 
8cffe5f135821e716117ee59bdd53139473bd1d8 
refs/remotes/origin/hello-1.x 
bb4fef88fee435bfac04b8389cf193d9c04105a6 
refs/remotes/origin/helper/master 
cf71ae3515e36a59c7f98b9db825fdof2a318350 
refs/remotes/origin/helper/vi.x 
c4acab26ff1c1125f5e585ffa8284d27f8ceea55 
refs/remotes/origin/master 


3171561b2c9c57024f7d748ala5cfd755a26054a refs/tags/jx/v1.0 
aaff5676a7c3ae7712af61dfb9ba05618c74bbab refs/tags/jx/v1.0-i1i8n 
e153f83ee75d25408f7e2fd8236ab1i8c0abfOec4 refs/tags/jx/v1.1 
83f59c7a88c04ceb703e490a86dde9af41de8bcb refs/tags/jx/v1. 
1581768ec71166d540e662d90290cb6f82a43bb0 refs/tags/jx/v1. 
ccca267c98380ea7fffb241f103d1ie6f34d8bc01 refs/tags/jx/v2. 
8a5b9934aacdebb72341dcadbb2650cf626d83da refs/tags/jx/v2. 
89b74222363e8cbdf91aab30d005e697196bd964 refs/tags/jx/v2. 
gb4ec63aea44b96d498528dcf3e72e1255d79440 refs/tags/jx/v2. 
60a2f4f31e5dddd777c6ad37388fe6e5520734cb refs/tags/mytag 
5dc2fc52f2dcb84987f511481cc6b71ec1b381f7 refs/tags/mytag3 
51713af444266d56821fe3302ab44352b8c3eb71 refs/tags/v1.0 


OPOOWD 


从 git show-ref 的 输出 中 发 现 了 几 个 不 寻常 的 引用 ， 这 些 引 用 以 
refsremotes/origin/ 为 前 缀 ， 并 且 名 称 和 远程 版 本 库 的 分 文 名 一 一 对 
应 。 这 些 引 用 实际 上 就 是 从 远程 版 本 库 的 分 文 复制 过 来 的 ， 称 为 远程 
分 支 。 


Git 的 git branch 命 令 也 能 够 查看 这 些 远 程 分 文 ， 不 过 要 加 上 "-r" 参 


$git branch-r 

origin/HEAD- >origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi.x 
origin/master 


Git 这 样 的 设计 是 非常 巧妙 的 ， 在 从 远程 版 本 库 执行 获取 操作 时 ， 
不 是 把 远程 版 本 库 的 分 文 原封 不 动 地 复制 到 本 地 版 本 库 的 分 文中 ， 而 
是 复制 到 另外 的 命名 空间 。 如 在 克隆 一 个 版 本 库 时 ， 会 将 远程 分 文 都 
复制 到 目录 .git/refs/remotes/origin/ 下 。 这 样 从 不 同 的 远程 版 本 库 执行 获 


取 操 作 ， 因 为 通过 命名 空间 的 相互 隔离 ， 所 以 驶 避免 了 在 本 地 的 相互 


复 疝 。 

那么 殉 隆 操作 产生 的 远程 分 文 为 什么 都 有 一 个 名 为 "origin/" 的 前 绥 
呢 ? 奥秘 欧 在 配置 文件 .gityconfig 中 。 下 面 的 几 行内 容 出 目 该 配置 文 
| 于 了 人 讽 因 太 便 是 二 于 行 叶 2 


6[remote "origin"] 
7 fetch=+refs/heads/*:refs/remotes/origin/* 
8 url=file:///path/to/repos/hello-world.git 


这 个 小 下 可 以 称 为 remote] 小 让， 该 小 节 以 origin 为 名 注册 了 一 个 
远程 版 本 库 。 该 版 本 库 的 URL 地 址 由 第 8 行 给 出 ， 会 发 现 这 个 URL 地 址 
就 是 执行 git clone 命 令 时 所 用 的 地 址 。 最 具 魔 法 的 配置 是 第 7 行 ， 这 一 
行 设置 了 执行 git fetch origin 操 作 时 使 用 的 默认 引用 表达 式 : 


该 引用 表达 式 以 加 号 (+) 开头 ， 含 义 是 强制 进行 引用 的 替换 ， 
即使 即将 进行 的 蔡 换 十 非 快 进 式 的 。 


引用 表达 式 中 使 用 了 通配符 ， 冒 号 前 面 的 含有 通配符 的 引用 指 的 
征 远 程 版 本 库 的 所 有 分 文 ， 冒 号 后 面 的 引用 含义 是 复制 到 本 地 的 远程 
2 


正 因 为 有 了 上 面 的 [remote] 配 置 小 节 ， 当 执行 git fetch origin 操 作 
时 ， 束 相当 于 执行 了 下 面 的 命令 ， 将 远程 版 本 库 的 所 有 分 支 复 制 为 本 


地 的 远程 分 文 。 


git fetch origin+refs/heads/*:refs/remotes/origin/* 


远程 分 支 不 古 真 正 意义 上 的 分 文 ， 是 类 似 于 里 程 碑 一 样 的 引用 。 
如 有 果 针 对 远程 分 文 执 行 检 出 命令 ,会 看 到 大 段 的 错误 警告 。 


$git checkout origin/hello-1.x 

Note:checking out 'origin/hello-1.x'. 

You are in 'detached HEAD' state.You can look around,make 
experimental 

changes and commit them,and you can discard any commits you make 
in this 

state without impacting any branches by performing another 
checkout. 

If you want to create a new branch to retain commits you 
create,you may 

do so(now or later)by using-b with the checkout command 
again.Example: 

git checkout-b new_branch_name 

HEAD is now at 8cffe5f...Merge branch 'hello-1.x' of 

file:///path/to/repos/hello-world into hello-1.x 


上 面 大 段 的 错误 信息 实际 上 告诉 我 们 一 件 事 ， 远 程 分 文 类 似 于 里 
程 碑 ， 如 果 检 出 就 会 使 得 头 指针 HEAD 处 于 分 离 头 指针 状态 。 实 际 上 
除了 以 refs/heads 为 前 缀 的 引用 之 外 ， 如 采 检 出 任何 其 他 引用 ， 都 将 使 
工作 区 处 于 分 离 头 指针 状态 。 如 果 对 远程 分 文 进行 修改 就 需要 创建 新 
的 本 地 分 文 。 


19.2 ”分 文 奶 中 
为 了 能 够 在 远程 分 文 refs/remotes/origin/hello-1.x 上 进行 工作 ， 需 要 
基于 该 远程 分 文 创建 本 地 分 文 。 远 程 分 文 可 以 使 用 简写 origin/hello- 
1.X。 如 果 Git 的 版 本 是 1.6.6 或 更 新 的 版 本 ， 可 以 使 用 下 面 的 命令 同时 完 
成 分 文 的 创建 和 切换 。 
$git checkout hello-1.x 
Branch hello-1.x Set up to track remote branch hello-1.x from 


origin. 
Switched to a new branch 'hello-1.x' 


如 果 Git 的 版 本 比较 老 ， 或 注册 了 多 个 远程 版 本 库 ， 因 此 存在 多 个 
名 为 hello-1.x 的 远程 分 支 ， 就 不 能 使 用 上 面 简洁 的 分 支 创建 和 切换 全 
令 ， 而 需要 使 用 在 上 一 章 中 学 习 到 的 分 支 创建 命令 ， 显 式 地 从 远程 分 
支 中 创建 本 地 分 支 。 

Rao Lo SGU Ob to track nete anh Nolo Epon 
ea to a new branch 'hello-1.x' 

在 上 面 基于 远程 分 支 创建 本 地 分 支 的 过 程 中 ， 命 令 输出 的 第 一 行 
说 的 是 建立 了 本 地 分 支 和 远程 分 支 的 跟踪 。 和 远程 分 支 建立 跟踪 后 ， 
本 地 分 支 就 具有 下 列 特征 : 


检查 工作 区 状态 时 ， 会 显示 本 地 分 文 和 被 跟 踩 远程 分 文 提交 之 间 
的 关系 。 


当 执行 git pul 命 令 时 ， 会 和 被 跟 踩 的 远程 分 文 进行 合并 (或 者 变 
基 ) ， 如 果 两 者 出 现 版 本 偏离 的 话 。 


当 执行 git push 命 令 时 ， 会 推送 到 远程 版 本 库 的 同名 分 文中 。 


下 面 就 在 基于 远程 分 文 创建 的 本 地 跟踪 分 文中 进行 操作 ， 看 看 本 
地 分 支 是 如 何 与 远程 分 文 建立 天 联 的 ， 具 体操 作 过 程 如 下 。 


(1) 先 将 本 地 hello-1.x 分 支 向 后 重 置 两 个 版 本 。 


$git reset--hard HEADAA^ 
HEAD is now at ebcf6d6 blank commit for GnuPG-signed tag test. 


(2) 然 后 查看 状态 ,显示 当前 分 文 相 比 跟踪 分 支 落 后 了 3 个 版 本 。 
之 所 以 落后 三 个 版 本 而 非 两 个 版 本 是 因为 hello-1.x 的 最 新 提交 是 
一 个 合并 提交 ， 包 含 两 个 父 提交 ， 因 此 上 面 的 重 转 命令 丢弃 控 了 二 个 


提交 。 


从 


$git status 

#0n branch hello-1.x 

#Your branch is behind'origin/hello-1.x'by 3 commits,and can be 
fast- 

forwarded. 

# 


nothing to commit(working directory clean) 


(3) 执行 git pull 命 令 ， 会 自动 与 跟踪 的 远程 分 支 进行 合并 ， 相 当 
于 找 回 最 新 的 3 个 提交 。 


$git pull 

Updating ebcf6d6. .8cffesf 

Fast-forward 

SrCc/Vmain.c| 工 1+ 二 十 十 十 十 十 十 十- - 

1 files changed,9 insertions(+),2 deletions(-) 


但 是 如 果 基 于 本 地 分 支 创 建 男 外 一 个 本 地 分 支 则 没有 分 支 跟 踪 的 
功能 。 下 面 就 从 本 地 的 hello-1.x 分 支 中 创建 hello-jx 分 支 。 


(1) 从 hello-1.x 分 支 中 创建 新 的 本 地 分 支 hello-jx。 


下 面 的 创建 分 文 操作 只 有 一 行 输 出 ， 看 不 到 分 文 间 建立 跟 踩 的 提 


小 ° 


$git checkout-b hello-jx hello-1.x 
Switched to a new branch ‘hello-jx' 


(2) 将 hello-jx 分 支 重 置 。 


$git reset--hard HEADAA^ 
HEAD is now at ebcf6d6 blank commit for GnuPG-signed tag test. 


(3) 检查 状态 看 不 到 分 支 间 的 跟踪 信息 。 


$git status 
#0n branch hello-jx 
nothing to commit(working directory clean) 


(4) 执行 git pull 命 令 会 报错 。 


$git pull 

You asked me to pull without telling me which branch you 
want to merge with,and 'branch.hello-jx.merge' in 

your configuration file does not tell me,either.Please 
specify which branch you want to use on the command line and 
try again(e.g.'git pull<repository> <refspec>'). 

See git-pull(1)for details. 

If you often merge with the same branch,you may want to 

use something like the following in your configuration file: 
[branch "hello-jx"] 

remote=<nickname> 

merge=<remote-ref> 

[remote"<nickname>"] 

url=<url> 

fetch=<refspec> 

See git-config(1)for details. 


将 上 面 命令 执行 中 的 钳 误 信息 翻译 过 才 来 ， 就 是 : 


$git pull 

您 让 我 执行 拉 回 操作 , 但 是 没有 告诉 我 您 希望 与 哪个 远程 分 支 进行 合并 ， 

而 且 也 没有 通过 配置 'branch.hello-jx.merge' 来 告诉 我 。 

请 在 命令 行 中 提供 足够 的 参数 , 如 'git pull<repository><refspec>'。 
或 者 如 果 您 经 常 与 同一 个 分 支 进行 合并 , 可 以 和 该 分 支 建立 跟踪 。 在 配置 
中 添加 如 下 配置 信息 : 
[branch "hello-jx"] 
remote=<nickname> 
merge=<remote-ref> 
[remote "<nickname>"] 
url=<url> 
fetch=<refspec> 


为 什么 用 同样 方法 建立 的 分 支 hello-1.x 和 hello-jx， 奔 距 咱 就 那么 
大 呢 ? 奥秘 束 在 于 从 远程 分 文 创建 本 地 分 文 ， 目 动 建立 了 分 文 间 的 跟 


踪 ， 而 从 一 个 本 地 分 文 创 建 刀 外 一 个 本 地 分 文 则 没有 。 看 看 配置 文 
件 .giVyconfig 中 是 不 是 专门 为 分 文 hello-1.x 创 建 了 相应 的 配置 信息 ? 


9[branch "master"] 

10 remote=origin 

11 merge=refs/heads/master 
12[branch "hello-1.x"] 

13 remote=origin 

14 merge=refs/heads/hello-1.x 


其 中 第 9 一 11 行 古 针 对 master 分 文 设置 的 分 文 间 跟踪 ， 是 在 版 本 库 
克隆 的 时 候 目 动 建立 的 。 而 第 12 一 14 行 是 前 面 基于 远程 分 文 创建 本 地 
分 支 时 建立 的 。 至 于 分 文 hello-jx 则 没有 建立 相关 的 配置 。 


如 果 布 望 在 基于 一 个 本 地 分 文 创建 男 外 一 个 本 地 分 支 时 也 能 够 使 
用 分 文 间 的 跟踪 功能 ， 融 要 在 创建 分 文 时 提供 --track 参 数 。 下 面 实践 
一 下 ， 具 体操 作 过 程 如 下 。 


(1) 删除 之 前 创建 的 hello-jx 分 支 。 


$git checkout master 

Switched to branch 'master' 

$git branch-d hello-jx 

Deleted branch hello-jx(was ebcf6d6). 


(2) 使 用 参数 --track 重 新 基于 hello-1.x 创 建 hello-jx 分 支 。 


$git checkout--track-b hello-jx hello-1.x 
Branch hello-jx set up to track local branch hello-1.x. 
Switched to a new branch ‘hello-jx' 


(3) 从 Git 库 的 配置 文件 中 会 看 到 为 hello-jx 分 支 设置 的 跟踪 。 


因为 跟 踊 的 是 本 版 本 库 的 本 地 分 支 ， 所 以 第 16 行 设置 的 远程 版 本 
连 鸭 名字 四 
15 [branch "hello-jx"] 


16 remote=. 
17 merge=refs/heads/hello-1.x 


19.3 ”远程 版 本 库 


名 为 origin 的 远程 版 本 库 是 在 版 本 库 克 隆 时 注册 的 ， 那 么 如 何 注 册 
新 的 远程 版 本 库 呢 ? 


1. 注 册 远 程 版 本 库 
下 面 将 版 本 库 fle:///path/to/repos/hello-user1.git 以 new-remote 为 名 进 
行 注册 。 
$git remote add new-remote file:///path/to/repos/hello-user1.git 


如 果 再 打开 版 本 库 的 配置 文件 .git/config 会 看 到 新 的 配置 。 


12 [remote"new-remote"] 
13 url=file:///path/to/repos/hello-user1.git 
14 fetch=+refs/heads/*:refs/remotes/new-remote/* 


执行 git remote 命 令 ， 可 以 更 为 方便 地 显示 已 经 注册 的 远程 版 本 
库 o 


$git remote-v 

new-remote file:///path/to/repos/hello-user1.git(fetch) 
new-remote file:///path/to/repos/hello-user1.git(push) 
origin file:///path/to/repos/hello-world.git(fetch) 
origin file:///path/to/repos/hello-world.git(push) 


现在 执行 git fetch 并 不 会 从 新 注 册 的 new-remote 远 程 版 本 库 中 获 
取 ， 因 为 当前 分 文 设置 的 默认 远程 版 本 库 为 origin。 要 想 从 new-remote 
远程 版 本 库 中 获取 ， 需 要 为 git fetch 命 令 增 加 一 个 参数 new-remote 。 


$git fetch new-remote 

From file:///path/to/repos/hello-user1 

*[new branch]jhello-1.x->new-remote/hello-1.x 

*[new branch]jhelper/master->new-remote/helper/master 
*[new branch]jhelper/vi.x->new-remote/helper/vi.x 
*[new branch]master->new-remote/master 


从 上 面 的 命令 输出 中 可 以 看 出 ， 远 程 版 本 库 的 分 文 复制 到 本 地 版 
本 库 前 级 为 new-remote 的 远程 分 文中 去 了。 用 git branch-r 命 令 可 以 看 到 
新 增 了 几 个 远程 分 支 。 


$git branch-r 
new-remote/hello-1.x 
new-remote/helper/master 
new-remote/helper/vi.x 
new-remote/master 
origin/HEAD- >origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi.x 
origin/master 


2. 更 改 远程 版 本 库 的 地 址 


如 果 远 程 版 本 库 的 URL 地 址 改变 ， 需 要 更 换 ， 该 如 何 处 理 呢 ? 手 
工 修改 .git/config 文 件 是 一 种 方法 ， 用 git config 命 令 进 行 更 改 是 第 二 种 
方法 ， 还 有 一 种 方法 是 用 git remote 命 令 ， 如 下 : 


$git remote set-url new-remote file:///path/to/repos/hello- 
user2.git 


可 以 看 到 注册 的 远程 版 本 库 的 URL 地 址 已 经 更 改 。 


$git remote-v 

new-remote file:///path/to/repos/hello-user2.git(fetch) 
new-remote file:///path/to/repos/hello-user2.git(push) 
origin file:///path/to/repos/hello-world.git(fetch) 
origin file:///path/to/repos/hello-world.git(push) 


从 上 面 的 输出 中 可 以 发 现 每 一 个 远程 版 本 库 都 显示 两 个 URL 地 
址 ， 分 别 是 执行 git fetch 和 git push 命 令 时 用 到 的 URL 地 址 。 有 既然 有 两 个 
地 址 ， 就 意味 着 这 两 个 地 址 可 以 不 同 ， 用 下 面 的 命令 可 以 为 推送 操作 
设置 单独 的 URL 地 址 。 


$git remote set-url--push new-remote/path/to/repos/hello- 
user2.git 

$git remote-v 

new-remote file:///path/to/repos/hello-user2.git(fetch) 

new-remote/path/to/repos/hello-user2.git(push) 

origin file:///path/to/repos/hello-world.git(fetch) 

origin file:///path/to/repos/hello-world.git(push) 


当 单 独 为 推送 设置 了 URL 后 ， 配 置 文件 .giyconfig 的 对 应 [remote] 
小 和 也 会 增加 一 条 新 的 名 为 pushurl 的 配置 。 如 下 : 


12 [remote "new-remote"] 

13 url=file:///path/to/repos/hello-user2.git 

14 fetch=+refs/heads/*:refs/remotes/new-remote/* 
15 pushurl=/path/to/repos/hello-user2.9git 


3. 更 改 远程 版 本 库 的 名 称 


如 果 对 远程 版 本 库 的 注册 名 称 不 满意 


， 也 可 以 进行 修改 。 例 如 将 


new-remote 名 称 修 改 为 user2， 使 用 下 面 的 命令 : 


$git remote rename new-remote user2 


完成 改名 后 ， 不 但 远程 版 本 库 的 注册 名 称 更 改过 来 了 ， 就 连 远 程 


分 文 的 名 称 都 会 目 动 进行 相应 的 更 改 。 可 以 通过 执行 git remote 和 git 


branch-r 命 令 查看 。 


$git remote 

origin 

USer2 

$git branch-r 
origin/HEAD- >origin/master 
origin/hello-1.x 
origin/helper/master 
origin/helper/vi.x 
origin/master 
user2/hello-1.x 
user2/helper/master 
user2/helper/vi.x 
user2/master 


4. 远 程 版 本 库 更 新 


当 注册 了 多 个 远程 版 本 库 并 布 望 获 取 所 有 远程 版 本 库 的 更 新 时 ， 


Git 提 供 了 一 个 简单 的 命令 。 


$git remote update 
Fetching origin 


Fetching user2 


如 果 某 个 远程 版 本 库 不 想 在 执行 git remote update 时 获得 更 新 ， 可 
以 通过 参数 关闭 上 自动 更 新 。 例 如 下 面 的 命令 关闭 远程 版 本 库 user2 的 目 
动 更 狐 。 


$git config remote.user2.skipDefaultUpdate true 
$git remote update 
Fetching origin 


5. 删 除 远程 版 本 库 


如 果 想 要 删除 注册 的 远程 版 本 库 ， 用 git remote 的 rm 子 命令 可 以 实 
现 。 例 如 删除 注册 的 user2 版 本 库 。 


$git remote rm user2 


19.4 PUSH 和 PULL 操 作 与 远程 版 本 库 


Git 分 文 一 章 已 经 介绍 过 对 于 新 建立 的 本 地 分 支 (没有 建立 和 远程 
分 支 的 追踪 ) ， 执 行 git push 命 令 是 不 会 被 推送 到 远程 版 本 库 中 的 ， 这 
样 的 设置 是 非常 安全 的 ， 避 免 了 因为 误 操作 将 本 地 分 文 创 建 到 远程 版 
本 库 中 。 当 不 带 任 何 参数 执行 git push 命 令 时 ， 实 际 的 执行 过 程 是 : 

如 果 为 当前 分 文 设 置 了 <remote> ， 即 由 配置 branch. < 


branchname > .remote 给 出 了 远程 版 本 库 代 号 ， 则 不 带 参 数 执行 git push 
相当 于 执行 了 git push<remote 之 。 


如 果 没 有 为 当前 分 支 设 置 <remote > ， 则 不 带 参 数 执行 git push 相 
当 于 执行 了 git push origin 。 


要 推送 的 远程 版 本 库 的 URL 地 址 由 remote. <remote > .pushurl 给 
出 。 如 果 没 有 配置 ， 则 使 用 remote.<remote> .url 配 置 的 URL 地 址 。 


如 果 为 注册 的 远程 版 本 库 设置 了 push 参 数 ， 即 通过 remote.< 
remote > .push 配 置 了 一 个 引用 表达 式 ， 则 使 用 该 引用 表达 式 执行 推 


否则 使 用 “:” 作 为 引用 表达 式 。 该 表达 式 的 含义 是 同名 分 支 推送 ， 
即 对 所 有 在 远程 版 本 库 中 有 同名 分 支 的 本 地 分 支 执行 推送 。 


这 也 殊 是 为 什么 在 一 个 本 地 新 建 分 文中 执行 git push 推 送 操作 不 会 
推送 也 不 会 报错 的 原因 ， 因 为 远程 不 存在 同名 分 文 ， 所 以 根本 束 没 有 
对 该 分 文 执行 推送 。 而 如 果 本 地 其 他 分 文 在 远程 版 本 库 有 同名 分 文 且 
本 地 包含 更 新 的 话 ， 会 对 这 些 分 支 进 行 推送 。 


在 Git 分 支 一 章 中 就 已 经 知道 ， 如 果 需 要 在 远程 版 本 库 中 创建 分 
支 ， 则 执行 命令 ，git push <remote > <new_branch>。 即 通过 将 本 地 
分 文 推送 到 远程 版 本 库 的 方式 在 远程 版 本 库 中 创建 分 文 。 但 是 在 接 下 
来 的 使 用 中 会 遇 到 麻烦 : 不 能 执行 git pull 操 作 (不 带 参 数 ) 将 远程 版 
本 库 中 其 他 人 推送 的 提交 获取 到 本 地 。 这 是 因为 没有 建立 本 地 分 支 和 
远程 分 支 的 追踪 ， 即 没有 设置 branch.<branchname > .remote 的 值 和 


branch.<branchname > .merge 的 值 。 
关于 不 带 参 数 执行 git pull 命 令 的 解释 如 下 : 


如 果 为 当前 分 文 设置 了 <remote> ， 即 由 配置 branch. < 
branchname > .remote 出 了 远程 版 本 库 代 号 ， 则 不 带 参 数 执行 git pull 相 
当 于 执行 了 git pull <remote>。 


如 果 没 有 为 当前 分 支 设置 <remote > ， 则 不 融 参 数 执行 git pull 相 
当 于 执行 了 git pull origin 。 


要 获取 的 远程 版 本 库 的 URL 地 址 由 remote. <remote > .url 给 


如 果 为 注册 的 远程 版 本 库 设 置 了 fetch 参 数 ， 即 通过 remote.< 
remote > .fetch 配 置 了 一 个 引用 表达 式 ， 则 使 用 该 引用 表达 式 执 行 获 取 
操作 。 


接 下 来 要 确定 合并 的 分 支 。 如 果 设 定 了 branch. < branchname 
> .merge， 则 对 其 设 定 的 分 文 执行 合并 ， 人 否则 报错 退出 。 


在 执行 git pull 操 作 的 时 候 可 以 通过 参数 --rebase 设 置 使 用 变 基 而 非 
合并 操作 ， 将 本 地 分 支 的 改动 变 基 到 跟踪 分 支 上 。 为 了 避免 因为 态 记 
使 用 --rebase 参 数 导致 分 支 的 合并 ， 可 以 执行 如 下 命令 进行 设置 。 注 意 
将 <branchname> 替换 为 对 应 的 分 文 名 称 。 


$git config branch.<branchname> .rebase true 


有 了 这 个 设置 之 后 ， 如 果 是 在 <branchname> 工作 分 支 中 执行 git 
pull 命 令 ， 在 遇 到 本 地 分 支 和 远程 分 支出 现 偏离 的 情况 时 ， 会 采用 变 
其 操作 ， 而 不 是 默认 的 合并 操作 。 


如 果 为 本 地 版 本 库 设 置 参数 branch.autosetuprebase， 值 为 tue， 则 
在 基于 远程 分 文 建立 本 地 奶 蹊 分 文 时 ， 会 目 动 配 置 branch.< 
branchname > .rebase 人 参数 ， 在 执行 git pull 命 令 时 使 用 变 基 操作 取代 默 
认 的 合并 操作 。 


19.5 里程 碑 和 远程 版 本 库 


远程 版 本 库 中 的 里 程 碑 同 步 到 本 地 版 本 库 ， 会 使 用 同样 的 名 称 ， 
而 不 会 像 分 文 那 样 移 动 到 另外 的 命名 空间 《远程 分 文 ) 中， 这 可 能 会 
给 本 地 版 本 库 中 的 里 程 碑 之 来 混乱 。 当 和 多 个 远程 版 本 库 交 互 时 ， 这 
个 问题 吏 更 为 严重 。 


前 面 的 Git 里 程 牧 一 草 已 经 介绍 了 当 执 行 git push 命 令 推 送 时 ， 软 认 
不 会 将 本 地 创建 的 里 程 碑 带 入 远程 版 本 库 ， 这 样 可 以 避免 远程 版 本 库 
上 里 程 碑 的 泛滥 。 但 是 执行 git fetch 命 令 从 远程 版 本 库 获 取 分 文 的 最 新 
提交 时 ， 如 有 果 获 取 的 提交 上 建 有 里 程 碑 ， 这 些 里 程 碑 会 被 获取 到 本 地 
版 本 库 。 当 删除 注册 的 远程 版 本 库 时 ， 远 程 分 支 会 被 删除 ， 但 是 该 远 
程 版 本 库 引 入 的 里 程 碑 不 会 被 删除 ， 日 积 月 素 本 地 版 本 库 中 的 里 程 碑 


可 能 会 变 得 愈加 混乱 。 


可 以 在 执行 git fetch 命 令 的 时 候 ， 设 置 不 获取 里 程 碑 只 获取 分 文 及 
提交 。 通 过 提供 -n 或 --no-tags 参 数 可 以 实现 。 示 例如 下 : 


$git fetch--no-tags file:///path/to/repos/hello-world.git\ 
refs/heads/*:refs/remotes/hello-world/* 


在 注册 远程 版 本 库 的 时 候 ， 也 可 以 使 用 --no-tags 参 数 ， 避 人 免 将 远 
程 版 本 库 的 里 程 碑 引 入 本 地 版 本 库 。 例 如 : 


$git remote add--no-tags hell-worild\ 
file:///path/to/repos/hello-world.git 


19.6 ”分 文 和 里 程 修 的 安全 性 


通过 前 面 革 市 的 探讨 ， 会 感觉 到 Git 的 使 用 真 的 是 太 方 便 、 太 灵活 
了 ， 但 是 需要 掌握 的 知识 点 和 名 门 也 太 多 了 。 为 了 避免 没有 经 验 的 用 
尸 在 团队 共 至 的 Git 版 本 库 中 误 操 作 ， 束 需要 对 版 本 库 进 行 一 些 安全 上 
的 设置 。 本 书 第 5 篇 Git 服 务 右 搭建 的 相关 章 广 会 具体 介绍 如 何 配 置 用 
户 授权 等 版 本 库 安 全 性 设置 。 


实际 上 Git 版 本 库 本 喘 也 提供 了 一 些 安 全 机 制 避免 对 版 本 库 的 人 破 
坏 。 


用 reflog 记 录 对 分 文 的 操作 有 历史。 


默认 创建 的 融 工 作 区 的 版 本 库 都 会 包含 core.logallrefupdates 为 true 
的 配置 ， 这 样 在 版 本 库 中 建立 的 每 个 分 文 都 会 创建 对 应 的 reflog。 但 是 
创建 的 襟 版 本 库 默 认 不 包含 这 个 设置 ， 也 残 不 会 为 每 个 分 文 设 置 
reflog。 如 有 果 团 队 的 规模 较 小 ， 可 能 因为 分 文 误 操 作 寻 致 数据 丢失 ， 可 
以 考虑 为 宰 版 本 库 添加 core.logallrefupdates 的 相关 配置 。 


关闭 非 快 进 式 推 送 。 


如 果 将 配置 receive.denyNonFastForwards 设 置 为 tue， 则 禁止 一 切 
非 快 进 式 推送 。 但 这 个 配置 有 些 矫 枉 过 正 ， 更 好 的 方法 是 搭建 基于 


SSH 协 议 的 Git 服 务 絮 ， 通 过 钧 子 脚本 更 灵活 地 进行 配置 。 例 如 : 允许 
来 目 某 些 用 户 的 强制 提交 ， 而 其 他 用 户 不 能 执行 非 快 进 式 推送 。 
关闭 分 文 删除 功能 。 
如 果 将 配置 receive.denyDeletes 设 置 为 tue， 则 禁止 删除 分 文 。 同 
样 更 好 的 方法 是 通过 架设 基于 SSHI 夫 议 的 Git 服 务 絮 ， 配 置 除 的 
用 户 权 限 。 


> 
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第 20 章 ”补丁 文件 交互 


之 前 各 个 章 下 的 版 本 库 间 的 交互 都 是 通过 git push 和 /或 git pull 命 令 
来 实现 的 ， 这 是 Git 最 主要 的 交互 模式 ， 但 并 不 是 全 部 。 使 用 补丁 文件 
征 另 外 一 种 交互 方式 ， 适 用 于 参与 者 众多 的 大 型 项 目 进行 的 分 布 式 开 
发 。 例 如 Git 项 目 本 喘 的 代码 提交 束 主 要 由 页 献 者 通过 邮件 传递 补丁 文 
件 来 实现 的 。 作 者 在 写 书 过 程 中 发 现 了 Git 的 两 个 Bug， 就 是 以 补丁 形 
式 通 过 邮件 贡献 给 Git 项 目的 ， 下 面 两 个 链接 束 是 相关 邮件 的 存档 。 


关于 Git 文 档 错误 的 Bugfix: 
http:/marc.info/?1=git&cm=129248415230151 
关于 git-apply 的 一 个 Bugfix: 


http://article.gmane.org/gmane.comp.version-control.git/162100 


这 种 使 用 补丁 文件 进行 提交 的 方式 可 以 提高 项 目的 参与 度 。 因 为 
任何 人 都 可 以 参与 项 目的 开发 ， 只 要 会 将 提交 转化 为 补丁 ， 会 发 邮件 


印 可 。 


20.1 创建 补丁 


Git 提 供 了 将 提交 批量 转换 为 补丁 文件 的 命令 : git format-patch 。 
该 命令 后 面 的 参数 是 一 个 版 本 范围 列表 ， 会 将 包含 在 此 列表 中 的 提交 
一 一 转换 为 补丁 文件 ， 每 个 补丁 文件 包含 一 个 序号 并 从 提交 说 明 中 所 
取 字 符 串 作为 文件 名 。 


下 面 演示 一 下 在 userl 工 作 区 中 ， 如 何 将 master 分 文 的 最 近 3 个 提交 
转换 为 补丁 文件 。 (1) 进入 userl 工 作 区 ， 切 换 到 master 分 支 。 
$cd/path/to/user1i/workspace/hello-world/ 


$git checkout master 
$git pull 


(2) 执行 下 面 的 命令 将 最 近 3 个 提交 转换 为 补丁 文件 。 


$git format-patch-s HEAD~3. .HEAD 
0001-Fix-typo-help-to-help.patch 
0002-Add-I18N-support.patch 

0003-Translate-for-Chinese.patch 


在 上 面 的 git format-patch 命 令 中 使 用 了 -s 参 数 ， 会 在 导出 的 补丁 文 
件 中 添加 当前 用 户 的 签名 。 这 个 等 名 并 非 GnuPG 式 的 数字 签名 ， 不 过 
征 将 作者 姓名 添加 到 提交 说 明 中 而 已 ， 和 在 本 书 第 2 篇 开头 介绍 的 git 
commit-s 命 令 的 效 末 相同 。 虽 然 签 名 很 不 起 腿 ， 但 是 对 于 以 补丁 的 方 
式 提 交 数 据 却 非常 重要 ， 因 为 以 补丁 方式 的 提交 可 能 因为 合并 冲突 或 
其 他 原因 使 得 最 终 提 区 的 作者 ID 显示 为 代为 提交 的 项 目 管理 员 的 ID， 
在 提交 说 明 中 加 入 原始 作者 的 署名 信息 大 概 是 作者 唯一 露脸 的 机 会 。 


如 果 在 提交 时 起 了 使 用 -s 参 数 添 加 签名 ， 可 以 在 用 git format-path 命 令 
创建 补丁 文件 的 时 候补 救 。 


看 一 下 补丁 文件 的 文件 涉 ， 在 下 面 代码 中 的 第 7 行 可 以 看 到 新 增 的 


1 From d81896e60673771ef1873b27a33f52df75f70515 Mon Sep 17 
00:00:00 2001 

2 From:user1i<user1i@sun.ossxp.com> 

3 Date:Mon,3 Jan 2011 23:48:56+0800 

4 Subject:[PATCH 1/3]Fix typo:-help to--help. 


Se off-by:user1i<useriQ@sun.ossxp.com> 


ee c|2+- 
0 1 files changed,1 insertions(+),1 deletions(-) 


5 
6 
7 
8 
9 
1 
补丁 文件 有 一 个 类 似 邮 件 一 样 的 文件 头 〈 第 1~4 行 ) ， 提 交 日 志 
的 第 一 行 作为 邮件 标题 (Subject) ， 其 余 的 提交 说 明 作 为 邮件 内 容 
(如 有 果 有 的 话 ) ， 文 件 补丁 用 三 个 横 线 和 提交 说 明 分 开 。 


实际 上 这 些 补 丁 文件 可 以 直接 拿 来 作为 邮件 发 送 给 项 目的 负责 
人 。Git 提 供 了 一 个 辅助 邮件 发 送 的 命令 git send-email。 下 面 用 该 命令 
将 这 三 个 补丁 文件 以 邮件 的 形式 发 送出 去 。 


$git send-email*.patch 

0001-Fix-typo-help-to-help.patch 

0002-Add-I18N-support.patch 

0003-Translate-for-Chinese.patch 

The following files are 8bit,but do not declare a Content- 
Transfer-Encoding. 


0002-Add-I18N-Support ,patch 

0003-Translate-for-Chinese.patch 

Which 8bit encoding should I declare[UTF-8]? 

Who should the emails appear to be from?[user1< 
user1Q@sun.ossxp.com> |] 

Emails will be sent from:user1i<user1i@sun.ossxp.com> 

Who should the emails be sent to?jiangxin 

Message-ID to be used as In-Reply-To for the first email? 


send this email?([yjes|[n]jol[q]juitl[a]l11)3:a 


命令 git send-email 提 供 交 互 式 字符 界面 ， 输 入 正确 的 收 件 人 地 
址 ， 邮 件 残 批量 地 发 送出 去 了 。 


20.2 ”应 用 补丁 


在 前 面 通过 git send-email 命 令 发 送 邮件 给 jiangxin 用 户 。 现 在 使 用 


Linux 上 的 mail 命 令 检 查 一 下 邮件 。 


$mail 

Mail version 8.1.2 01/15/2001.Type?for help. 

"/var/mail/jiangxin":3 messages 3 unread 

>N 1 useri@sun.ossxp.c Thu Jan 13 18:02 38/1120[PATCH 1/3]Fix 
typo:-help 

to--help. 

N 2 user1iQ@sun.ossxp.c Thu Jan 13 18:02 227/6207 

=?UTF-8?q?=5BPATCH=202/3=5D=20Add=20I18N=20support=2E?= 

N 3 user1iQ@sun.ossxp.c Thu Jan 13 18:02 95/2893 

=?UTF-8?q?=5BPATCH=203/3=5D=20Translate=20for=20Chinese=2E?= 

cz 


如 果 邮 件 不 止 这 三 封 ， 需 要 将 三 个 包含 补丁 的 邮件 挑选 出 来 保存 


到 另外 的 文件 中 。 例 如 在 mail 命 令 的 提示 符 《此 ) 下 输入 命令 将 选 定 
的 邮件 保存 为 单独 的 文件 。 


&s 1-3 User1-mail-archive 
"user1i-mail-archive" [New file] 
&q 
上 面 的 操作 在 本 地 创建 了 一 个 由 开发 者 userl 的 补丁 邮件 组 成 的 归 
档 文 件 userl-mail-archive， 这 个 文件 是 mbox 格 式 的 ， 可 以 用 mail 命 令 


打开 。 


$mail-f user1i-mail-archive 

Mail version 8.1.2 01/15/2001.Type?for help. 

"user1i-mail-archive":3 messages 

>1 useri@sun.ossxp.c Thu Jan 13 18:02 38/1121[PATCH 1/3]Fix 
typo:-help 

to--help. 

2 useriQ@sun.ossxp.c Thu Jan 13 18:02 227/6208=?UTF-8?d? 
=5BPATCH=202/3=5D= 

20Add=20I18N=20support=2E?= 

3 useriQ@sun.ossxp.c Thu Jan 13 18:02 95/2894=?UTF-8?q? 
=5BPATCH=203/3=5D= 

20Translate=20for=20Chinese=2E?= 

&q 


使 用 git am 命 令 可 以 使 得 保存 在 mbox 中 的 邮件 批量 地 应 用 在 版 本 
库 中 。am 是 apply email 的 缩写 。 下 面 就 演示 一 下 如 何 使 用 git am 命令 应 
用 补丁 ， 有 具体 操作 过 程 如 下 。 


(1) 基于 HEAD~3 版 本 创建 一 个 本 地 分 支 ， 以 便 在 该 分 文 下 应 
4 


$git checkout-b user1 HEAD~3 
Switched to a new branch 'user1' 


(2) 将 mbox 文 件 userl-mail-archive 中 的 补丁 全 部 应 用 在 当前 分 支 
a oO 


$git am user1i-mail-archive 
Applying:Fix typo:-help to--help. 
Applying:Add I18N support. 
Applying:Translate for Chinese. 


(3) 补丁 成 功 应 用 上 了 ， 看 看 提交 日 志 。 


$git 10g-3--pretty=fuller 

commit 2d9276af9df1ia2fdb71id1ie7c9ac6dff88b2920a1 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Thu Jan 13 18:02:03 2011+0800 
Commit:user1i<user1i@sun.ossxp.com> 
CommitDate:Thu Jan 13 18:21:16 2011+0800 
Translate for Chinese. 

Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 
Signed-off-by:user1i<user1i@sun.ossxp.com> 
commit 41227f492ad37cdd99444a5f5ccoc27288f2bca4 
Author:Jiang Xin<jiangxin@ossxp.com> 
AuthorDate:Thu Jan 13 18:02:02 2011+0800 
Commit:user1i<user1i@sun.ossxp.com> 
CommitDate:Thu Jan 13 18:21:15 2011+0800 

Add I18N support. 

Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 
Signed-off-by:user1i<user1i@sun.ossxp.com> 
commit 4a3380fb7ae90039633dec84acc2aab85398efad 
Author:user1<user1i@sun.ossxp.com> 
AuthorDate:Thu Jan 13 18:02:01 2011+0800 
Commit:user1i<useriQ@sun.ossxp.com> 
CommitDate:Thu Jan 13 18:21:15 2011+0800 

Fix typo:-help to--help. 
Signed-off-by:user1i<user1i@sun.ossxp.com> 


从 提交 信息 中 可 以 看 出 : 
是 交 的 时 间 信 息 使 用 了 邮件 发 送 的 时 间 。 
作者 (Author) 的 信息 被 保留 ， 和 补丁 文件 中 的 一 致 。 


提交 者 (Commit) 全 都 设置 为 user1， 因 为 提交 是 在 user1 的 工作 
区 完成 的 。 


提交 说 明 中 的 签名 信息 被 保留 。 实 际 上 git am 命 令 也 可 以 提供 -s 参 
数 ， 在 提交 说 明 中 附加 执行 命令 用 户 的 签名 。 


对 于 不 习惯 在 控制 台 用 mail 命 令 接 收 邮 件 的 用 户 ， 可 以 通过 邮件 
附件 、U 熏 或 其 他 方式 获取 git format-patch 生 成 的 补丁 文件 ， 将 补丁 文 
件 保存 在 本 地 ， 通 过 管道 符 调 用 git am 命令 应 用 补丁 。 


$1s*.patch 

0001-Fix-typo-help-to-help.patch ©0002-Add-I18N-support.patch 
0003-Translate-for-Chinese.patch 

$cat*.patch|git am 

Applying:Fix typo:-help to--help. 

Applying:Add I18N support. 

Applying:Translate for Chinese. 


Git 还 提供 一 个 命令 git apply， 可 以 应 用 一 般 格式 的 补丁 文件 ， 但 
是 不 能 执行 提交 ， 也 不 能 保持 补丁 中 的 作者 信息 。 实 际 上 git apply 命 令 
和 GNU patch 命 令 类 似 ， 细 微 差 别 将 在 本 书 第 7 篇 的 “第 38 草 ”补丁 中 的 
二 进 制 文件 "中 予以 介绍 。 


20.3 StGit 和 Quilt 


一 个 复杂 功能 的 开发 一 定 是 由 多 个 提交 来 完成 的 ， 对 于 在 以 接收 
和 应 用 补丁 文件 为 开发 模式 的 项 目 中 ， 复 杂 的 功能 需要 通过 多 个 补丁 
文件 来 完成 。 补 丁 文件 因为 要 经 过 审核 才能 被 接受 ， 因 此 针对 一 个 功 
能 的 多 个 补丁 文件 一 定 要 保证 各 个 都 是 精品 : 补丁 1 用 来 完成 一 个 功能 
点 ， 补 本 2 用 来 完成 第 二 个 功能 点 ， 等 等 。 一 定 不 能 出 现 这 样 的 情况 : 
补丁 3 用 于 修正 补丁 1 的 错误 ， 补 本 10 改 正 了 补丁 7 中 的 文字 错误 ， 等 
等 。 这 样 就 带 来 补丁 管理 的 难题 


实际 上 基于 特性 分 支 的 开发 义 何 疾 不 是 如 此 ? 在 将 特性 分 支 归 并 
到 开发 主线 前 ， 要 接受 团队 的 评审 ， 特 性 分 支 的 开发 者 一 定 想 将 特性 
分 文 上 的 提交 进行 重 整 ， 把 一 些 提交 合并 或 拆 分 。 使 用 变 基 命令 可 以 
实现 提交 的 重 整 ， 但 是 操作 起 来 会 比较 困难 ， 有 什么 好 办 法 呢 ? 


20.3.1 StGit 


StGit 1 是 Stacked Git 的 简称 。StGit 就 是 解决 上 面 提 到 的 两 个 难题 
的 答案 。 实 际 上 StGit 在 设计 上 参考 了 一 个 著名 的 补丁 管理 工具 Quilt， 
并 且 可 以 输出 Quilt 兼 容 的 补丁 列表 。 在 本 节 的 后 半 部 分 会 介绍 Quilt。 


StGit 是 一 个 Python 项 目 ， 安 装 起 来 还 是 很 方便 的 。 在 
Debian/Ubuntu 下 ， 可 以 直接 通过 包 管 理 器 安装 : 


$sudo aptitude install stgit stgit-contrib 


下 面 还 是 用 hello-world 版 本 库 ， 进 行 StGit 的 实践 。 


(1) 首先 检 出 hello-world 版 本 库 。 


$cd/path/to/my/workspace/ 
$git clone file:///path/to/repos/hello-world.git stgit-demo 
$cd stgit-demo 


(2) 在 当前 工作 区 初始 化 StGit 。 


$stg init 


(3) 现在 补丁 列表 为 空 。 


$stg series 


(4) 将 最 新 的 三 个 提交 转换 为 StGit 补 丁 。 


$stg uncommit-n 3 

Uncommitting 3 patches... 

Now at patch "translate-for-chinese" 
done 


(67 现在 休 秆 列 下 中 村主 祝 允 件 训 


第 一 列 是 补丁 的 状态 符号 。 加 号 (+) 代表 该 补丁 已 经 应 用 在 版 
本 库 中 ， 大 于 号 《> ) 用 于 标识 当前 的 补丁 。 


$stg ser 
+fix-typo-help-to-help 
+add-i1i8n-support 
>translate-for-chinese 


(6) 现在 查看 master 分 文 的 日 志 ， 发 现 和 之 前 没有 两 样 。 


$git 10g-3--oneline 

c4acab2 Translate for Chinese. 
683448a Add I18N support. 
d81896e Fix typo:-help to--help. 


(7) 执行 StGit 补 丁 出 栈 的 命令 ， 会 将 补丁 撤 出 应 用 。 使 用 -a 参 数 
会 将 所 有 补丁 撤 出 应 用 。 


$stg pop 

Popped translate-for-chinese 

Now at patch "add-i1i8n-support" 

$stg pop-a 

Popped add-i1i8n-support--fix-typo-help-to-help 
No patch applied 


(8) 再 来 看 看 版 本 库 的 日 志 ， 会 发 现 最 新 的 三 个 提交 都 不 见 了 。 


$git 10g-3--oneline 

10765a7 Bugfix:allow spaces in username. 

0881ca3 Refactor:use getopt_long for arguments parsing. 
ebcf6d6 blank commit for GnuPG-signed tag test. 


(9) 查看 补丁 列表 的 状态 ， 会 看 到 每 个 补丁 前 都 用 减 号 (-) 标 


$stg ser 
-fix-typo-help-to-help 
-add-i1i8n-support 
-translate-for-chinese 


(10) 执行 补丁 入 栈 ， 即 应 用 补丁 ， 使 用 命令 stg push 或 stg goto， 
注意 stg push 命 令 和 git push 命 令 风 马 牛 不 相 及 。 


$stg push 

Pushing patch "fix-typo-help-to-help"...done(unmodified) 
Now at patch "fix-typo-help-to-help" 

$stg goto add-i1i8n-support 

Pushing patch "add-i1i8n-support"...done(unmodified) 

Now at patch "add-i1i8n-support" 


(11) 现在 处 于 应 用 add-il8n-support 让 本 的 状态 。 这 个 补丁 有 些 
问题 ， 本 地 化 语言 模板 有 错误 ， 我 们 来 修改 一 下 。 


$cd src/ 
$rm locale/helloworld.pot 
$make po 
xgettext-s-k_-o locale/helloworld.pot main.c 
msgmerge locale/zh_CN/LC_MESSAGES/helloworld.po 
locale/helloworld.pot-o locale/temp.po 
mv locale/temp.po locale/zh_CN/LC MESSAGES/helloworld.po 


(12) 现在 查看 工作 区 ， 发 现 工作 区 有 改动 。 


$git status-s 


M locale/helloworld.pot 
M locale/zh_CN/LC_MESSAGES/helloworld.po 


(13) 不 要 提交 ， 而 是 执行 stg refresh 命 令 更 新 补丁 。 


$stg refresh 
Now at patch "add-i1i8n-support" 


(14) 这 时 再 查看 工作 区 ， 发 现 本 地 修改 不 见 了 。 
$git status-s 

(15) 执行 stg show 会 看 到 当前 的 补丁 add-i18n-support 已 经 更 新 。 
$stg show 

(16) 将 最 后 一 个 补丁 应 用 到 版 本 库 ， 遇 到 冲突。 这 是 因为 最 后 


一 个 补丁 是 对 中 文本 地 化 文件 的 翻译 ， 因 为 翻译 前 的 模板 文件 被 更 改 
了 所 以 造成 了 冲突 。 


$stg push 

Pushing patch "translate-for-chinese"...done(conflict) 
Error:1 merge conflict(s) 

CONFLICT(content):Merge conflict in 
src/locale/zh_CN/LC_MESSAGES/helloworld.po 

Now at patch "translate-for-chinese" 


(17) 这 个 冲突 文件 很 好 解决 ， 直 接 编辑 冲突 文件 helloworld.po 
即 可 。 编 辑 好 之 后 ， 注 意 一 下 第 50 行 和 第 62 行 是 否 像 下 面 写 的 一 样 。 


N| 
Y 


浪 


50 "hello-h,--help\n" 
51 "显示 本 帮助 页 。\n" 


61 msgid "Hi," 
62 msgstr "您 好 ," 


(18) 执行 git add 命 令 完成 冲突 解决 。 


$git add locale/zh_CN/LC_MESSAGES/helloworld.po 


(19) 不 要 提交 ， 而 是 使 用 stg refresh 命 令 更 新 补丁 ， 同 时 更 新 提 


$stg refresh 
Now at patch "translate-for-chinese" 
$git status-s 


(20) 看 看 修改 后 的 程序 ， 是 不 是 都 能 显示 中 文 了 。 


$./hello 

世界 你 好 。 
(version:v1i.0-5-g733c6ea) 
$./hello Jiang Xin 
您 好 , Jiang Xin. 
(version:v1.0-5-g733c6ea) 
$./hello-h 


(21) 导出 补丁 ， 使 用 命令 stg export。 导 出 的 是 Quilt 格 式 的 补丁 


$cd/path/to/my/workspace/stgit-demo/ 


$stg export-d patches 
Checking for changes in the working directory...done 


(22) 看 看 导出 补丁 的 目标 目录 。 


$1s patches/ 
add-i1i8n-support fix-typo-help-to-help series translate-for- 
chinese 


(23) 其 中 文件 series 是 补丁 文件 的 列表 ， 列 在 前 面 的 补丁 先 被 应 
用 。 
$cat patches/series 
#This series applies on GIT commit 
d81896e60673771ef1873b27a33f52df75f70515 
fix-typo-help-to-help 


add-i1i8n-support 
translate-for-chinese 


通过 上 面 的 演示 可 以 看 出 StGit 可 以 非常 方便 地 对 提交 进行 整理 ， 
整理 提交 时 无 须 使 用 复杂 的 变 基 命令 ， 而 是 采用 提交 StGit 化 、 修 改 文 
件 、 执 行 stg refresh 的 工作 流程 即 可 更 新 补丁 和 提交 。StGit 还 可 以 将 补 
丁 导 出 为 补丁 文件 ， 虽 然 导 出 的 补丁 文件 没有 像 git format-patch 那 样 加 
上 代表 顺序 的 数字 前缀 ， 但 是 用 文件 series 标 注 了 补丁 文件 的 先后 顺 
序 。 实 际 上 可 以 在 执行 stg export 时 添加 -n 参 数 为 补丁 文件 添加 数字 前 


> 
局 


StGit 还 有 一 些 功 能 ， 如 合并 补丁 /提交 ， 插 入 新 补丁 /所 区 等 ， 请 
参照 StGit 帮 助 ， 想 不 一 一 举例 。 


[1| http:/www.procode.org/stgit/ 


20.3.2 Quilt 


Quilt 是 一 款 补 丁 列表 管理 软件 ， 用 Shell 语 言 开 发 ， 安 装 也 很 简 
单 ， 在 Debian/Ubuntu 上 直接 用 下 面 的 命令 即 可 安装 : 


$sudo aptitude install quilt 


Quilt 约 定 俗 成 将 补丁 集 放 在 项 目 根 目 隶 下 的 子 目录 patches 中 ， 否 
则 需要 通过 环境 变量 QUILT_PATCHES 对 路 径 进 行 设置 。 为 了 减少 麻 
烦 ， 在 上 面 用 stg export 导 出 种 丁 的 时 候 整 导出 到 了 patches 目 录 下 。 


简单 说 一 下 Quilt 的 使 用 ， 会 发 现 真 的 和 StGit 很 像 ， 实 际 上 十 先 有 
的 Quilt， 后 有 的 StGit。Quilt 使 用 过 程 如 下 。 


(1) 重 置 到 三 个 提交 前 的 版 本 ， 否 则 应 用 补丁 的 时 候 会 失败 。 不 
要 起 了 删除 src/locale 目 隶 。 


$git reset--hard HEAD~3 
$rm-rf src/locale/ 


(2) 显示 补丁 列表 。 


$quilt series 
01-fix-typo-help-to-help 
02-add-i1i8n-support 
03-translate-for-chinese 


(3) 应 用 一 个 补丁 。 


$quilt push 


Applying 
patching 


patch 01-fix-typo-help-to-help 
file src/main.c 


Now at patch 01-fix-typo-help-to-help 


(4) 下 一 个 补丁 是 什么 ? 


$quilt next 
02-add-i1i8n-support 


(5) 应 用 全 部 补丁 。 


$quilt push-a 


Applying 
patching 
patching 
patching 
patching 
Applying 
patching 


patch 02-add-i1i8n-support 

file src/Makefile 

file src/locale/helloworld.pot 

file src/locale/zh_CN/LC_MESSAGES/helloworld.po 
file src/main.c 

patch 03-translate-for-chinese 

file src/locale/zh_CN/LC_MESSAGES/helloworld.po 


Now at patch 03-translate-for-chinese 


Quilt 的 功能 还 有 很 多 ， 请 参照 Quilt 的 在 线 帮助 ， 恕 不 一 一 举例 。 


Git 提 供 了 一 个 名 为 git quiltimport 的 命令 ， 可 以 非常 方便 地 将 Quilt 
格式 的 补丁 集 转化 为 一 个 一 个 的 Git 提 交 ， 是 前 面 介 绍 的 git am 命令 的 
一 个 补充 。 例 如 要 将 位 于 patches 目 孙 下 的 Quilt 让 本 集 应 用 到 版 本 库 


中 ， 可 以 执行 下 面 的 命令 : 


$git quiltimport 


[1| http://savannah.nongnu.org/projects/quilt 
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分 布 式 的 版 本 控制 会 不 会 造成 开发 中 的 无 序 ， 导 致 版 本 管理 的 裔 
溃 ? 习惯 了 如 Subversion 这 类 集中 式 版 本 控制 系统 的 用 户 一 定 会 有 这 个 
疑问 。 


作为 分 布 式 版 本 控制 系统 ， 每 一 个 克隆 都 是 一 个 完整 的 版 本 库 ， 
可 以 提供 一 个 版 本 控制 服务 右 所 能 提供 的 一 切 服 务 ， 即 每 个 人 的 电脑 
都 是 一 台 服 务 器 。 与 之 相反 ， 像 Subversion 那 样 的 集中 式 版 本 控制 系 
统 ， 只 拥有 唯一 的 版 本 控制 服务 右 ， 所 有 团队 成 员 都 使 用 客户 端 与 之 
交互 ， 大 部 分 操作 要 通过 网 络 传输 来 实现 。 对 于 习惯 了 和 唯一 服务 大 
交互 的 团队 ， 转 换 到 Git 后 ， 该 如 何 协同 团队 的 工作 呢 ?“ 第 21 章 ”经 
典 Git 协 同 模型 ”会 介绍 集中 式 和 人 金字塔 式 两 种 主要 的 协同 工作 模型 。 


基于 茶 个 项 目 进 行 二 次 开发 ， 需 要 使 用 不 同 的 工作 模型 。 原 始 的 
项 目 称 为 上 游 项 目 ， 不 能 直接 在 上 游 项 目 中 提交 ， 可 能 是 因为 授权 的 
原因 ， 或 者 是 因为 目标 用 户 的 需求 不 同 。 这 种 基于 上 游 项 目 进 行 二 次 
开发 ， 实 际 上 是 对 各 个 独特 的 功能 分 文 进行 管理 ， 同 时 又 能 对 上 游 项 
目的 开发 进度 进行 兼 收 并 蓄 式 的 合并 。“ 第 22 章 ”Topgit 协 同 模型 ”会 


扩 介 绍 这 一 方面 的 内 容 。 


多 个 版 本 库 组 成 一 个 项 目 ， 在 实际 应 用 中 并 不 罕见 。 一 部 分 原因 
可 能 是 版 本 库 需 要 依赖 第 三 方 的 版 本 库 ， 这 时 第 23 革 介绍 的 “ 子 模 组 协 
同 模 型 * 就 可 以 派 上 用 场 了 。 有 的 时 候 还 要 对 第 三 方 的 版 本 库 进行 定 
制 ,，“ 第 24 革 ” 子 树 合并 ”提供 了 一 个 解决 方案 。 有 的 时 候 ， 为 了 管理 
方便 (授权 或 项 目 确实 太 庞杂 ) ， 多 个 版 本 库 共同 组 成 一 个 大 的 项 
目 ， 例 如 Google Android 项 目 就 是 由 近 200 个 版 本 库 组 成 的 。“ 第 25 章 
Android 式 多 版 本 库 协同 ”提供 了 一 个 非常 有 趣 的 解决 方案 ， 解 决 了 “ 子 
模 组 协同 模型 "管理 上 的 难题 。 


在 本 篇 的 最 后 〈 第 26 章 ) ， 会 介绍 git-svn 这 一 工具 。 可 能 因为 公 
司 对 代码 严格 的 授权 要 求 ， 而 不 能 将 公司 的 版 本 控制 服务 絮 从 
Subversion 迁 移 到 Git (实际 可 以 通过 对 Git 版 本 库 细 粒度 拆 分 实现 授权 
管理 ，， 可 是 这 并 不 能 阻止 个 人 使 用 git-svn 作 为 前 端 工具 操作 
Subversion 版 本 库 。git-svn 可 以 让 Git 和 Subversion 完 美 地 协同 工作 。 


第 21 章 ”经典 Git 协 同 模 型 


21.1 集中 式 协 同 模型 


可 以 像 集中 式 版 本 控制 系统 那样 使 用 Git， 在 一 个 大 家 都 可 以 访问 到 的 服务 器 上 架设 Git 
服务 器 ， 所 有 人 都 可 以 从 该 服务 器 克隆 代码 ， 将 本 地 提交 推送 到 服务 器 上 ， 如 图 21-1 所 示 ， 


21-1 集中 式 协同 模型 


回忆 一 下 在 使 用 Subversion 等 集中 式 版 本 控制 系统 时 ， 对 服务 器 管理 上 的 要 求 ， 
口 只 允许 拥有 账号 的 用 户 访问 版 本 库 . 

口 甚至 只 允许 用 户 访问 版 本 库 中 的 某 些 路 径 ， 其 他 路 径 则 不 能 访问 。 

口 特定 目录 只 允许 特定 用 户 执 行 写 操作 。 

口服 务 器 可 以 通过 和 钧 子 实现 特殊 功能 ， 如 对 commit log 的 检查 、 数 据 镜 像 等 。 

对 于 这 些 需求 ，Git 大 部 分 都 能 支持 ， 共 至 能 够 做 到 更 多 ， 

口 可 以 设置 谁 能 访问 版 本 座 ， 谁 不 能 访问 版 本 库 。 

口 具 有 更 丰富 的 写 操作 授权 。 可 以 限制 哪些 分 支 不 允许 写 ， 哪 些 路 径 不 允许 写 。 
口 可 以 设置 谁 能 够 创建 新 的 分 支 。 

口 可 以 设置 谁 能 够 创建 新 的 版 本 库 。 

口 可 以 设置 谁 能 够 强制 更 新 ， 

口服 务 器 端 同样 支持 钧 子 脚本 。 


当然 想 要 完整 地 实现 上 述 的 功能 需求 ， 需 要 使 用 特殊 的 服务 器 软件 (如 Gitolite) 来 染 
设 Git 服务 器 ， 这 也 是 通过 Git 实现 传统 集中 式 工作 模型 的 核心 。 在 本 书 第 5 篇 介绍 服务 器 
部 署 的 时 候 ， 会 介绍 如 何 用 Gitolite 架设 Git 服务 上 器， 以 实现 集中 式 协 同 模 型 对 版 本 库 授权 
和 管理 上 的 要 求 。 

但 是 也 要 承认 ， 在 “ 读 授权 ”上 Git 做 不 到 很 精细 ， 这 是 分 布 式 版 本 控制 系统 的 机 制 使 
然 。 按 模块 分 解 Git 版 本 库 ， 并 结合 后 面 介绍 的 多 版 本 库 协 同 解决 方案 可 以 克服 Git 读 授 权 


的 局 限 。 
口 Git 不 支持 对 版 本 库 读 取 的 精确 授权 ， 只 能 是 非 0 即 1 的 授权 。 即 或 者 能 够 读 取 一 个 
版 本 库 的 全 部 ， 或 者 什么 也 读 不 到 。 
口 因 为 Git 的 提交 是 一 个 整体 ， 提 交 中 包含 了 完整 目录 树 (tree) 的 哈 希 值 ， 因 此 完整 
性 不 容 破 坏 。 
DGit 是 分 布 式 版 本 控制 系统 ， 如 果 克 许 不 完整 的 克隆 ， 那 么 本 地 就 是 截然 不 同 的 版 本 
库 ， 在 向 服务 器 推送 的 时 候 ， 会 被 拒绝 ， 或 者 产生 新 的 分 支 。 


21.1.1 传统 集中 式 协 同 模型 


对 于 简单 的 代码 修改 ， 可 以 像 传统 集中 式 版 本 控制 系统 (Subversion) 那样 工作 ,参照 
图 21-2 所 示 的 工作 流程 图 。 


21-2 ”集中 式 协同 模型 工作 流 1 


但 是 对 于 复杂 的 修改 〈 代 码 重 构 / 增加 复杂 功能 )， 这 个 工作 模式 就 有 些 不 合适 了 ， 

第 一 个 问题 是 : 很 容易 将 不 成 熟 的 代码 带 入 共享 的 版 本 库 ， 破 坏 共 享 版 本 库 相 应 分 
支 的 代码 稳定 性 。 例 如 破坏 编译 、 破 坏 每 日 集成 。 这 是 因为 开发 者 克隆 版 本 库 后 ， 直 接 
工作 在 默认 的 跟踪 分 支 上 ， 当 不 小 心 执 行 git Push 命令 时 ， 就 会 将 自己 的 提交 推送 到 
服务 器 上 。 

为 了 避免 上 面 的 问题 ， 开 发 者 可 能 会 延迟 推送 ， 在 软件 开发 的 整个 过 程 中 《例如 一 个 
月 ) 只 在 本 地 提交 ， 而 不 向 服务 器 推送 ， 这 样 会 产生 更 严重 的 问题 : 数据 丢失 。 开 发 者 可 能 
因为 操作 系统 感染 病毒 ， 或 者 不 小 心 删 除 目 录 ， 或 者 硬盘 故障 导致 工作 成 果 的 彻底 丢失 ， 这 
对 个 人 和 团队 来 说 都 是 灾难 。 

解决 这 个 问题 的 方法 也 很 简单 ， 就 是 在 本 地 创建 本 地 分 支 “功能 分 支 ;)， 并 且 同 时 在 服 
务 器 端 ‘ 共 享 版 本 库 ) 也 创建 自己 独 享 的 功能 分 支 。 本 地 提交 推送 到 共享 版 本 库 中 自己 狼 享 
的 分 支 上 。 当 开发 完成 之 后 ， 和 将 功能 分 支 合并 到 主线 上 ， 推 送 到 共享 版 本 库 ， 完 成 开发 。 当 
然 如 果 不 再 需要 该 特性 分 支 时 就 要 做 些 请 理工 作 。 参 见 图 21-3 所 示 的 工作 流程 图 ， 


git checkout 
-b MyjBranch 


gt push 
ongin 
MyjBranch 


it push 
origin 
My/Branch 


gg branch 
"dd My/Branch 
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21.1.2 ”Gerrit 特 殊 的 集中 式 协 同 模型 


1. 传统 集中 式 协同 模型 的 缺点 
传统 集中 式 协 同 模型 的 主要 问题 是 在 管理 上 : 谁 能 够 向 版 本 库 推送 ? 可 以 信赖 某 人 向 版 
本 库 推送 吗 ? 
对 于 在 一 个 相对 固定 的 团队 内 部 使 用 集中 式 协同 模型 没有 问题 ， 
因为 大 家 彼此 信赖 ， 都 熟悉 项 目的 相关 领域 。 但 是 对 于 公开 的 项 目 
(开源 项 目 ) 来 说 ， 采 用 集中 式 的 协同 模型 ， 必 然 只 能 有 部 分 核心 人 

员 具 有 “ 写 ” 权 限 ， 很 多 有 能 力 的 参与 者 会 被 拒 之 门 外 ， 这 不 利于 项 目 
的 发 展 。 因 此 集中 式 协 同 模型 主要 应 用 在 公司 范围 内 和 商业 软件 开发 
中 ， 而 不 会 成 为 开源 项 目的 首选 。 


2. 强 制 代码 审核 的 集中 式 协同 模型 


Android 项 目 采 用 了 独 树 一 岩 的 集中 式 管 理 模型 一 一 通过 Gerrit 架 
设 的 审核 服务 絮 对 提交 进行 强制 审核 。Android 是 由 近 200 个 Git 版 本 库 
组 成 的 庞大 的 项 目 ， 为 了 对 庞大 的 版 本 库 进 行 管理 ，Android 项 目 开发 
了 两 个 工具 repo 和 Gerrit 进 行 版 本 库 的 管理 。 其 中 Gerrit 服 务 器 为 
Android 项 目 引 入 了 特别 的 集中 式 协 同 模型 。 


Gerrit 服 务 器 通过 SSH 协 议 管 理 Git 版 本 库 ， 并 实现 了 一 个 web 界面 
的 评审 工作 流 。 任 何 注册 用 户 都 可 以 参与 到 项 目 中 来 ， 都 可 以 将 Git 提 
区 推送 到 Gerrit 管 理 下 的 Git 版 本 库 〈 通 过 Gerrit 局 动 的 特殊 SSH 端 


口 ) 。Git 推 送 不 能 直接 推送 到 分 支 ， 而 是 推送 到 特殊 的 引用 refs/fov < 
branch-name > ， 此 提交 会 目 动 转换 为 形 如 refs/changes/<nn>/< 
review-id>/<patch-set> 的 补丁 集 ， 此 补丁 集 在 Gerrit 的 Web 界 面 中 显 
示 为 对 应 的 评审 任务 。 评 审 任务 进入 审核 流程 ， 通 过 相关 负责 人 的 审 
核 后 才 被 接受 ， 并 合并 到 正式 的 版 本 库 中 。 


本 书 的 第 5 篇 第 32 章 会 详细 介绍 Gerrit 代 码 审核 服务 器 的 部 署 和 使 


21.2 ”金字塔 式 协 同 模型 


自从 分 布 式 版 本 库 控制 系统 (MercuriayHg、Bazaar、Git 等 ) 诞生 
之 后 ， 有 越 来 越 多 的 开源 项 目 迁 移 了 版 本 控制 系统 ， 例 如 从 Subversion 
或 CVS 迁 移 到 分 布 式 版 本 控制 系统 。 因 为 众多 的 开源 项 目 逐 渐 认识 
到 ， 集 中 式 的 版 本 控制 管理 方式 阻止 了 更 多 的 人 参与 项 目的 开发 ， 对 
项 目的 发 展 不 利 。 


集中 式 版 本 控制 系统 的 最 大 问题 足 ， 如 琳 没 有 在 服务 句 端 授权 ， 
就 无 法 提交 ， 也 束 无 法 保存 目 己 的 更 改 。 开 源 项 目 虽 然 介 许 所 有 人 访 
问 代 码 库 ， 但 是 不 可 能 授权 “ 写 操作 ?给 所有 的 人 ， 人 否则 代码 质量 无 法 
控制 〈Gerrit 审 核 服务 器 是 例外 ) 。 与 此 相对 照 的 是 ， 在 使 用 了 分 布 式 
版 本 控制 系统 之 后 ， 任 何人 都 可 以 在 本 地 克隆 一 个 和 远程 版 本 库 一 模 
一 样 的 版 本 库 ， 本 地 的 版 本 库 允 许 任何 操作 ， 这 束 极 大 地 调动 了 开发 
者 投入 项 目 研 究 的 积极 性 。 


分 布 式 的 开发 必然 市 来 协同 的 问题 ， 如 何 能 够 让 一 个 到 不 相识 的 
开发 者 将 他 的 页 献 提交 到 项 目 中 ? 如 何 能 够 最 大 化 地 发 动 和 汇聚 全 球 
的 智慧 ? 开源 社区 逐渐 发 展 出 金字 塔 模型 (如 图 21-4 所 示 ) ， 而 这 也 
是 必然 之 选 。 


金字 塔 模型 的 售 义 是 ， 虽 然 理 论 上 每 个 开发 者 的 版 本 库 都 是 平等 
的 ， 但 是 会 有 一 个 公认 的 权威 的 版 本 库 ， 这 个 版 本 库 由 一 个 或 多 个 核 
心 开发 者 负责 维护 (具有 推送 的 权限 ) 。 核 心 的 开发 人 员 负 责 审核 其 
他 贡献 者 的 提交 ， 审 核 可 以 通过 邮件 传递 的 补丁 或 访问 (PULL) 贡献 
者 开放 的 代码 库 进 行 。 由 此 构成 了 以 核心 开发 团队 为 顶层 的 、 所 有 页 
献 者 共同 参与 的 开发 


者 使 字 塔 


1 
7 \ 
/ 的 


图 21-4 金字塔 式 协 间 模 型 


Linux 社区 就 是 上 典型 的 人 金字塔 结 构 。Linus Torvalds 的 版 本 库 是 公认 的 官方 版 本 库 ， 人 许 
上 忆 成 员 的 提交 。 其 他 贡献 者 的 提交 必须 经 过 一 个 丰 多 个 核心 成 员 的 审核 后 ， 才 能 经 四 核心 
成 员 代 为 推送 到 官方 版 本 库 . 

采用 这 种 金字 塔 式 协同 模型 不 需要 复杂 的 Git 服务 器 设置 ， 只 需要 项 目 管理 者 提供 一 个 
让 其 他 人 只 读 访 问 的 版 本 库 即 可 。 当 然 管 理 者 要 能 够 通过 某 种 方法 疝 该 版 本 库 推送 ， 以 便 其 
他 人 能 够 通过 该 版 本 库 获得 更 新 。 


21.2.1 页 献 痢 开放 只 该 版 本 库 


困 为 不 能 直接 向 项 目 只 读 共 享 的 版 本 库 提 交 ， 为 了 能 让 项 目的 管理 者 获取 自己 的 提交 ， 
贡献 者 需要 提供 项 目 管理 者 访问 自己 版 本 库 的 方法 。 建 立 一 个 自己 拥有 的 只 读 共 享 版 本 库 是 
-个 简单 易 行 的 方法 。 第 5 篇 “搭建 Git 服务 器 ”的 相关 章节 会 介绍 几 种 快速 搭建 只 读 Git 
版 本 库 的 方法 ， 包 括 : 用 HTTP 智能 协议 搭建 Git 服务 器 ， 用 Git 协议 搭建 Git 服务 器 
贡献 者 建立 自己 的 只 读 共 享 版 本 库 后 ， 需 要 检查 和 整理 自己 贡献 的 提交 ， 检 查 项 目 如 下 : 
口 贡 献 的 提交 要 处 于 一 个 单独 的 特性 分 支 中 ， 并 且 要 为 该 特性 分 支取 一 个 有 意义 的 名 字 
使 用 贡献 者 的 名 字 及 简单 的 概 插 性 文字 是 非常 好 的 特性 分 支 名 。 例 如 对 我 来 说 可 能 创 
建 名 为 jijangxin/fix-bug-xxx 的 分 支 。 
口 贡 献 的 提交 是 否 基 于 上 游 对 应 分 支 的 最 新 提交 ? 如 果 不 是 ， 需 要 变 基 到 上 游 最 新 提 
以 象 产生 合并 。 
项 目的 管理 者 会 尽量 避免 不 必要 的 合并 ， 因 此 会 要 求 贡 献 者 的 提交 尽 基 基于 项 目的 最 
新 提交 来 进行 。 使 用 下 面 的 方式 建立 跟踪 远程 分 支 的 本 地 分 支 ， 可 以 很 简单 地 实现 在 
执行 git Pull 操作 时 使 用 变 基 操作 取代 合并 操作 ， 


$git checkout-b jiangxin/fix-bug-xxx origin/master 
$git config branch.jiangxin/fix-bug-xxx.rebase true 
hack, hack, hack 

$git pull 


然后 贡献 者 束 可 以 同 项 目 管理 者 发 送 通 知 邮件 ， 告 诉 项 目 管理 者 
有 新 页 献 的 代码 等 每 他 的 审核 。 邮 件 中 大 致 包括 以 下 内 容 : 


为 什么 要 修改 项 目的 代码 。 


相应 的 修改 是 否 经 过 了 测试 ， 或 者 提交 中 是 否 包含 了 单元 测试 。 


目 己 版 本 库 的 访问 地 址 。 
等 性 分 文 的 名 称 。 


Git 提 供 了 一 个 名 为 git request-pull 的 命令 ， 可 以 非常 方便 地 生成 上 
述 信息 。 


21.2.2 ”以 补丁 方式 贡献 代码 
使 用 补丁 文件 方式 贡献 代码 也 是 开源 项 日 常用 的 协同 方式 。Git 项 
目 本 身 就 是 采用 该 方式 运作 的 。 运 作 方 式 如 下 : 
(1) 每 个 用 户 先 在 本 地 版 本 库 修 改 代 码 。 


(2) 修改 完成 后 ， 通 过 执行 git format-patch 命 令 将 提交 转换 为 补 


(3) 如 果 提 交 很 多 且 比 较 杂乱 ， 可 以 考虑 使 用 StGit 对 提交 进行 
重 整 。 


(4) 调用 git send-email 命 令 ， 或 者 通过 图 形 界面 的 邮件 客户 端 软 
件 将 补丁 发 给 邮件 列表 及 项 目 维护 者 。 
(5) 项目 维护 者 认可 贡献 者 提交 的 补丁 后 ， 执 行 git am 命令 应 用 
补丁 。 
第 3 篇 的 “第 20 章 ”补丁 文件 交互 "已 经 详细 介绍 了 该 模式 的 工作 流 
程 ， 请 参考 相关 章 和 。 


第 22 章 Topgit| 办 同 模型 


如 果 没 有 Topgit ， 就 不 会 有 此 书 。 因 为 发 现 了 Topgit， 我 才 下 定 决 心 在 公司 大 范围 推 
广 Git ; 因为 Topgit 才 激 发 了 我 对 Git 的 好 奇 之 心 。 


22.1 作者 版 本 控制 系统 的 三 个 里 程 碑 


1. Subversion 和 卖主 分 支 

从 2005 年 开始 我 专心 于 开源 软件 的 研究 、 定 制 开 发 和 整合 ， 在 这 之 后 的 几 年 ， 一 直 使 
用 Subversion 做 版 本 控制 。 对 于 定制 开发 工作 ，Subversion 有 一 种 称 为 卖主 分 支 (Vendor 
Branch) 的 模式 ， 


图 22-1 卖主 分 支 工作 模式 医 


卖主 分 支 的 工作 模式 如 图 22-1 所 示 : 

口 图 22-1 由 左 至 右 ， 提 交 随 着 时 间 而 递增 . 

口 主线 trunk 用 于 对 定制 开发 的 过 程 进行 跟踪 。 

口 主线 的 第 一 个 提交 w1 .0 是 导 人 人 上游“ 该 开源 软件 的 官方 版 本 库 ) 发布 的 版 本 。 

口 之 后 在 1.1 提交 之 处 建 并 分支， 是 为 卖主 分 支 (vendor branch)。 

口 主线 上 依次 进行 了 cl、c2 两 次 提交 ， 是 基于 v1.0 进行 的 定制 开发 。 

口上 游 有 了 新 版 本 ， 提 交 到 卖主 分 支 上 ， 即 v2 .0 提交 。 和 vv1.0 相 比 除了 大 基 的 文件 
更 改 外 ， 还 可 能 有 文件 增加 和 删除 ， 

口 然后 在 主线 上 执行 从 卖主 分 支 到 主线 的 合并 ， 即 提交 M1 ， 因 为 此 时 主线 上 的 改动 相 
对 较 少 ， 合 并 v2 .0 并 不 太 费 事 . 

口 主线 继续 开发 。 可 能 同时 有 针对 不 同 需求 的 定制 开发 ， 在 主线 上 会 有 越 来 越 多 的 失 
交 ， 如 上 图 从 c3 到 c99 的 近 百 次 措 交 。 


如 果 在 卖主 分 支 上 导入 上 游 的 新 版 本 v3.0， 合 并 将 会 非常 痛 冰 。 
因为 主线 上 针对 不 同 需求 的 定制 开发 已 经 混杂 在 一 起 了 | 


实践 证 明 ，Subversion 的 卖主 分 支 对 于 大 规模 的 定制 开发 非常 不 适 
合 。 癌 上 游 新 版 本 的 迁移 会 随 着 定制 功能 和 提交 的 增多 变 得 越 来 越 困 
难 。 


2.Hg 和 MQ 


在 2008 年 ， 我 们 的 版 本 库 迁 移 到 Mercurial (水 银 ， 叉 称 为 Hg) ， 
并 工作 在 "Hg+MQ" 模 式 下 ， 我 目 以 为 找到 了 定制 开发 版 本 控制 的 终极 
解决 方案 ， 那 时 我 们 已 被 Subversion 的 卖主 分 文 折 麻 得 太 久 了 。 


Hg 和 Git 一 样 也 十 一 种 分 布 式 版 本 控制 系统 ，MQ 十 Hg 的 一 个 扩 
展 ， 可 以 实现 提交 和 补丁 两 种 模式 之 间 的 转换 。Hg 版 本 库 上 的 提 区 可 
以 通过 hg qimport 命 令 转 化 为 补丁 列表 ， 也 可 以 通过 hg qpush 、hg qpop 
等 命令 在 补丁 列表 上 游 移 〈 出 栈 和 入 栈 ) ， 入 栈 的 补丁 转化 为 Hg 版 本 


相 比 Subversion 的 卖主 分 支 ， 使 用 "Hg+MQ" 的 好 人 处 在 于 : 


针对 不 同 需求 的 定制 开发 ， 其 提交 被 限定 在 各 目 独 立 的 补丁 文件 
中 而 不 会 混杂 在 一 起 。 


针对 同一 个 需求 的 定制 开发 ， 无论 多 少 次 的 更 改 都 体现 为 补丁 文 
件 的 变化 ， 而 补丁 文件 本 喘 也 是 被 版 本 控制 的 。 


各 个 补丁 之 间 是 顺序 依赖 和 关系， 形成 一 个 Quilt 格 式 的 补丁 列表 。 


同上 游 莉 版 本 迁 移 过 程 的 工作 量 降低 了 ， 除 了 因为 针对 各 个 功能 
的 定制 开发 被 隔离 ， 还 有 迁移 过 程 也 非常 具有 可 操作 性 。 


将 定制 开发 迁移 至 上 游 新 版 本 的 过 程 是 : 先 将 所 有 补丁 "出 栈 ”， 
再 将 上 游 新 版 本 提交 到 主线 ， 然 后 依次 将 补 本 "入 栈 ”。 如 果 上 游 新 版 
本 的 代码 改动 较 大 ， 补 丁 入 栈 可 能 会 过 到 冲突 ， 在 冲突 解决 完毕 后 执 
行 hg qref 命 令 即 可 完成 定制 开发 到 新 的 上 游 版 本 的 迁移 。 


但 是 如 果 需 要 在 定制 开发 上 进行 多 人 协作 ，"Hg+MQ" 的 星 病 下 显 
现 了 。 因 为 "Hg+MQ" 工 作 模式 下 ， 和 定制 开发 的 成 采 是 一 个 补丁 库 ， 在 
补丁 库 上 进行 协作 的 难度 非常 大 ， 当 发 生 冲 突 的 时 候 ， 补 丁 文件 本 号 
的 冲突 会 让 人 有 眼花 综 乱 。 这 束 引 发 了 我 们 第 三 次 版 本 控制 系统 大 于 
移 。 


3.Git 和 Topgit 


2009 年 ， 我 们 把 目光 锁定 在 Topgit 上 。Topgit 是 Topic Git 的 简写 ， 
是 用 shell 脚 本 语言 开发 的 辅助 工具 ， 对 Git 功 能 进行 了 扩展 ， 用 于 管理 
特性 分 支 的 开发 。Topgit 为 特性 分 支 引 入 了 基准 分 支 的 概念 ， 并 以 此 


管理 特性 分 文 间 的 依赖 ， 让 等 性 分 文 问 上 游 痢 版 本 的 迁移 变 得 非常 簿 
单 。 


Topgit 的 主要 特点 有 : 


上 游 的 原始 代码 位 于 开发 主线 (master 分 支 ) ， 而 每 一 个 定制 开 
发 都 对 应 于 一 条 Git 特 性 分 支 (refs/heads/t/feature name) 。 


特性 分 支 之 间 的 依赖 关系 不 像 "Hg+MQ" 那 样 是 逐一 依赖 模式 ， 而 
是 可 以 任意 设 定 
分 支 之 间 的 依赖 : 多 重 依赖 、 平 行 依赖 等 
口 特性 分 支 和 其 依赖 的 分 支 可 以 导出 为 Quilt 格式 的 补丁 列表 


口 因为 针对 某 一 需求 的 定制 开发 限定 在 特定 的 特性 分 支 中 ， 可 以 多 人 协同 参与 ， 和 正常 
的 Git 开发 别 无 二 致 ， 


[1| http://repo.or.cz/w/topgit.git 


22.2 ”Topgit 原 理 


图 22-2 是 一 个 近似 的 Topgit 实现 图 〔( 略 去 了 重要 的 top-bases 分 支 )。 


bl M1 M3 


(特性 分 支 B: refs/headsAt/B) 
(特性 分 支 A: refs/heads/t/A) 


(主线 /卖主 分 支 : master) 


(特性 分 支 C: refs/headsAt/C) 


图 22-2 Topgit 特性 分 支 关 系 图 


在 图 22-2 中 ， 主 线 上 的 w1 .0 是 上 游 版 本 的 一 次 提交 。 特 性 分 支 A 和 CC 都 直接 依赖 主 
线 master， 而 特性 分 支 B 则 依赖 特性 分 支 A。 提 交 M1 是 特定 分 支 B 因为 特性 分 支 A 更 新 
面 做 的 一 次 迁移 ， 提 交 M2 和 M4 则 分 别 是 特性 分 支 A 和 C 因为 上 游 出 现 了 新 版 本 v2 .0 而 
做 的 迁移 。 当 然 特性 分 支 B 也 要 做 相应 的 迁移 ， 是 为 M3， 

上 述 的 图 示 非 常 粗 糙 ， 因 为 如 果 按 照 这 样 的 设计 很 难 将 特性 分 支 导出 为 补丁 文件 ， 例 如 
特性 分 支 B 导出 为 补丁 ， 实 际 上 应 该 是 M2 和 M3 之 间 的 差异 ， 而 绝 不 是 a2 和 M3 之 间 的 
差异 。Topgit 为 了 能 够 实现 将 分 支 导出 为 补丁 ， 又 为 每 个 特性 的 开发 引 人 了 一 个 特殊 的 引用 
(refs/top-bases/*) ， 用 于 追踪 特性 分 支 的 “ 变 基 "， 称 为 特性 分 支 的 基 淮 分 支 。 所 有 特 
性 分 支 的 基准 分 支 也 形成 了 复杂 的 分 支 美 系 图 ， 如 图 22-3 所 示 。 


(特性 B 的 基准 分 支 : refs/top-bases/t/B) 
(特性 A 的 基准 分 支 : refsktop-bases/tJA) 


(主线 / 坎 主 分 支 ; master) 


《特性 C 的 基准 分 支 ;: refsjtop-bases/t/C) 


图 22-3 Topgit 特性 分 支 的 基准 分 支 关 系 图 
把 图 22-2 和 图 22-3 两 张 分 支 图 重合 ， 重 合 点 之 间 的 差异 就 可 用 于 将 特性 分 支 导出 为 补 


于 全 1 


上 面 的 特性 分 文 B 还 只 是 依赖 一 个 分 文 ， 如 果 出 现 一 个 分 文 依赖 
多 个 特性 分 文 的 话 ， 情 况 束 会 更 加 复杂 ， 也 更 能 体现 出 这 种 设计 方案 
的 精妙 。 


Topgit 还 在 每 个 特性 分 文 工 作 区 的 根 目录 引入 两 个 文件 ， 用 于 记 
录 分 文 的 依赖 及 关于 此 分 文 的 说 明 : 


文件 .topdeps 记 录 该 分 文 所 依赖 的 分 文 列 表 。 


该 文件 通过 tg create 命 令 在 创建 特性 分 文 时 目 动 创 建 ， 或 者 通过 tg 
depend add 命 令 来 添加 新 依赖 。 


文件 .topmsg 记 录 该 分 支 的 描述 信息 。 


该 文件 通过 tg create 命 令 在 创建 特性 分 文 时 创建 ， 可 以 手动 编辑 。 


22.3 Topgit 的 安装 


Topgit 用 shell 脚 本 语言 开发 ， 可 以 安装 在 所 有 的 类 Unix 环 境 中 ， 例 
如 Linux、Mac OS X， 以 及 Windows 下 的 Cygwin。 下 面 的 官方 网 站 链 
接 介 绍 了 Topgit 的 安装 和 使 用 方法 : http://repo.or.cz/w/topgit.git? 
a=blob;f=README 。 


1.Linux 下 安装 Topgit 


安装 官方 的 Topgit 版 本 ， 直 接 克 隆 官方 的 版 本 库 ， 执 行 make 即 
可 : 
$git clone git://repo.or.cz/topgit.git 
$cd topgit 


$make 
$make install 


默认 会 把 Topgit 的 可 执行 文件 tg 安装 在 $bHOME/bin (用 户主 目录 下 
的 bin 目 录 ) 下 ， 如 果 没 有 将 ~/bin 加 入 环境 变量 $PATH 中 ， 就 可 能 无 
法 执行 tg 命令 。 


如 果 具 有 root 权 限 ， 可 以 在 编译 和 安装 时 问 make 命 令 传递 prefix 变 
量 ， 将 Topgit 安 厂 在 系统 目录 中 。 


$make prefix=/usr 
$sudo make prefix=/usr install 


我 对 Topgit 做 了 一 些 增强 和 改进 趾 ， 在 后 面 的 章节 将 予以 介绍 。 
如 果 想 安 狠 改进 后 的 版 本 ， 需 要 预先 安装 Quilt 伞 丁 管理 工具 ， 然 后 进 
行 如 下 操作 。 
$git clone git://github.com/ossxp-com/topgit.git 
$cd topgit 
$QUILT_PATCHES=debian/patches quilt push-a 


$make prefix=/usr 
$sudo make prefix=/usr install 


如 果 用 的 是 Ubuntu 或 Debian Linux 操 作 系统 ， 还 可 以 这 么 安装 。 
(1) 先 安装 Debian/Ubuntu 打 包 依 赖 的 相关 工具 软件 。 


$sudo aptitude install quilt debhelper\ 
build-essential fakeroot dpkg-dev 


(2) 再 调用 dpkg-buildpackage 命 令 ， 编 译 出 DEB 包 ， 再 安装 。 


$git clone git://github.com/ossxp-com/topgit.git 
$cd topgit 

$dpkg-buildpackage-b-rfakeroot 

$sudo dpkg-i../topgit_*.deb 


(3) 安装 完毕 后 ， 重 新 加 载 命令 行 补 齐 ， 可 以 更 方便 地 使 用 tg 命 


今 。 


$./etc/bash_ completion 


2.Mac OS 又 下 安装 Topgit 


在 Mac OS X 下 安装 官方 版 本 的 Topgit， 在 使 用 中 会 遇 到 各 种 各 样 
的 问题 。 这 是 因为 Mac OS X 下 部 分 shell 命 令 的 行为 和 相应 的 GNU 命 令 
的 行为 不 一 致 ， 例 如 echo、paste 和 sed 命 令 等 。 


在 Mac OS 义 下 可 以 使 用 Homebrew 安 装 所 需 的 GNU 工 具 。 如 下 : 


$brew install gnu-sed 
$brew instal] quilt 


然后 别 扎 了 安装 改造 后 的 Topgit 。 


$git clone git://github.com/ossxp-com/topgit.git 
$cd topgit 

$QUILT_PATCHES=debian/patches quilt push-a 
$make prefix=/usr 

$sudo make prefix=/usr install 


3.Windows 下 安 效 Topgit 


Windows 下 的 msysGit 因 为 缺乏 Topgit 依 赖 的 命令 行 工 具 (如 
fgrep、install、make、mkfifo、mktemp、tsort 等 ) ， 安 装 和 运行 Topgit 
遇 到 困难 。 从 安装 好 的 MSYS 中 或 MSYS-CN 9 中 提取 所 需要 的 软 

ee 可 以 实现 Topgit 在 msysGit 中 的 安装 和 运行 。 


Windows 下 的 Cygwin 拥 有 一 个 完整 的 POSIX 环 境 ， 当 安装 了 所 需 
的 工具 (make、gquilt 思 等 后 ， 就 可 以 正常 地 编译 和 使 用 Topgit 。 


注意 如 果 克 隆 Topgit 版 本 库 后 工作 区 文件 的 换行 符 是 DOS 格 式 换 
行 符 (CRLF) ， 在 安装 过 程 中 会 遇 到 麻烦 。 克 隆 改 进 的 Topgit 则 不 会 
出 现 类 似 问 题 ， 这 是 因为 在 工作 区 根 目 录 下 存在 一 个 .gitattributes 中 | 文 
件 ， 可 以 保证 检 出 的 工作 区 文件 采用 Unix 格 式 的 换行 符 (LF) 


在 Cygwin 下 安装 改进 后 的 Topgit 使 用 如 下 方法 : 


$git clone git://github.com/ossxp-com/topgit.git 
$cd topgit 

$QUILT_PATCHES=debian/patches quilt push-a 
$make prefix=/usr 

$make prefix=/usr install 


[1] 我 对 Topgit 的 改进 采用 了 Topgit 的 开发 模式 ， 如 果 大 家 发 现 我 的 改 
动 没有 及 时 地 跟 上 上 游 代 码 ， 用 户 可 以 目 行 使 用 Topgit 将 改动 迁移 到 
最 新 的 上 游 版 本 。 还 要 提醒 的 是 ， 不 要 把 我 的 错 广 算 到 上 游 开 发 者 头 
Fs 

[2] http://www.mingw.org/wiki/msys 

[3] http://code.google.com/p/msys-cn/ 

[4] 如 果 要 安装 改进 后 的 Topgit 。 


[5] 参见 第 8 篇 第 40 章 “40.3 ”换行 符 问题 ”。 


22.4 Topgit 的 使 用 


通过 前 面 的 原理 部 分 ， 可 以 发 现 Topgit 为 管理 特性 分 文 所 引入 的 
配置 文件 和 基准 分 文 都 是 和 Git 兼 容 的 。 


在 refs/top-bases/ 命 名 空间 下 的 引用 ， 用 于 记录 特性 分 文 的 基准 分 
支 。 


在 特性 分 支 的 工作 区 根 目 录 下 引入 两 个 文件 .topdeps 和 .topmsg， 
用 于 记录 分 文 的 依赖 和 说 明 。 


引入 狐 的 钩子 脚本 hooks/pre-commit， 用 于 在 提交 时 检查 分 支 依 赖 
有 没有 发 生 循环 等 。 


Topgit 的 命令 行 的 一 般 格式 为 : 
tg[global option] <subcmd> [command_options...][arguments...] 


说 明 : 在 子 命令 前 的 全 局 选项 ， 目 前 可 用 的 只 有 -r<remote> ， 用 
于 设 定 远程 版 本 库 ， 默 认为 origin。 在 子 命令 后 可 以 跟 子 命令 相关 的 参 


数 。 


下 面 就 来 介绍 Topgit 常 用 的 子 命令 。 


1.tg help 命 令 


tg help 命 令 显 示 帮 助 信息 。 在 tg help 后 面 提供 子 命 令 名 称 ， 可 以 获 
得 该 子 命令 详细 的 帮助 信息 。 


2.tg create 命 令 

tg create 命 令 用 于 创建 新 的 特性 分 支 。 用 法 如 下 : 
tg[...]create NAME[DEPS...|-r RNAME] 

其 中 : 


NAME 是 新 的 特性 分 文 的 分 文 名 ， 必 须 提 供 。 一 般 约 定 俗 成 : 
NAME 以 V 前 缀 开头 的 表明 此 分 支 是 一 个 Topgit 特 性 分 文 。 


DEPS.…… 征 可 选 的 一 个 或 多 个 依赖 分 文 名 。 如 果 不 提 供 依赖 分 文 
和 名， 则 使 用 当前 分 文 作 为 新 的 特性 分 文 的 依赖 分 文 。 


-TRNAME 选 项 ， 将 远程 分 支 作 为 依赖 分 支 ， 不 党 用。 


tg create 命 令 会 创建 新 的 特性 分 支 refs/heads/INAME， 以 及 特性 分 
支 的 基准 分 支 refs/top-bases/INAME， 并 且 在 项 目 根 目录 下 创建 文 
件 .topdeps 和 .topmsg。 还 会 提示 用 户 编辑 .topmsg 文 件 ， 输 入 详细 的 特 


性 分 文 描述 信息 。 


为 了 试验 Topgit 命 令 ， 找 一 个 示例 版 本 库 或 干脆 创建 一 个 版 本 

库 。 在 示例 版 本 库 的 master 分 文 下 输入 如 下 命令 创建 一 个 名 为 Vfeaturel 
的 特性 分 文 : 

$tg create t/feature1 

tg:Automatically marking dependency on master 

tg:Creating t/featurel1 base from master... 

Switched to a new branch 't/featurel' 

tg:Topic branch t/featurel1 set up.Please fill.topmsg now and 
make initial commit. 


tg:To abort:git rm-f,.topxccgit checkout mastercctg delete 
t/feature1 


提示 信息 中 以 "tg: "开头 的 是 Topgit 产 生 的 说 明 。 其 中 提示 用 户 编 
辑 ，topmsg 文 件 ， 然 后 执行 一 次 提交 操作 完成 Topgit 特 性 分 文 的 创 
建 。 


如 果 想 撤销 此 次 操作 ， 删 除 项 目 根 日 好 下 的 .top* 文 件 ， 切 换 到 
master 分 文 ， 然 后 执行 tg delete UVfeature1 命 令 删 除 Vfeature1 分 文 及 特性 


分 支 的 基准 分 支 refs/top-bases/t/featurel 。 


输入 git status 可 以 看 到 当前 已 经 切换 到 tfeaturel 分 文 ， 并 且 Topgit 
已 经 创建 了 .topdeps 和 .topmsg 文 件 ， 并 已 将 这 两 个 文件 加 入 到 暂 存 
区 。 


$git status 

#0n branch t/featurel1 

#Changes to be committed: 

#(USe "git reset HEAD<file>..."to unstage) 
# 


#new file:.topdeps 
#new file:.topmsg 
# 

$cat ,topdeps 
master 


打开 .topmsg 文 件 ， 会 看 到 下 面 的 内 容 (前 面 增加 了 行 号 ) 


From:Jiang Xin<jiangxin@ossxp.com> 
Subject: [PATCH]t/feature1 


<patch description> 


ORODOP 


Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


其 中 第 2 行 是 关于 该 特性 分 文 的 简短 搞 述 ， 第 4 行 是 详细 描述 ， 可 


以 写 多 行 。 编辑 完成 ， 别 筷 了 提交 ， 提 区 之 后 才 完成 Topgit 分 文 的 创 
建 。 


$git add-u 
$git commit-m "create tg branch t/featurel1" 


如 果 这 时 想 创建 一 个 新 的 特性 分 支 Vfeature2， 并 且 也 是 要 依赖 


master， 注 意 需 要 在 命令 行 中 提供 master 作 为 第 二 个 参数 ， 以 设 定 依赖 
分 支 。 因 为 当前 所 处 的 分 支 为 Vfeaturel1， 如 果 不 提供 指定 的 依赖 分 支 
就 会 自动 依赖 当前 分 支 。 


$tg create t/feature2 master 
$git commit-m "create tg branch t/feature2" 


下 面 的 命令 将 创建 t/feature3 分 支 ， 该 分 支 依赖 t/featurel 和 
t/feature2 ° 


$tg create t/feature3 t/feature1 t/feature2 
$git commit-m "create tg branch t/feature3" 


3.tg info 命 令 


tg info 命 令 用 于 显示 当前 分 文 或 指定 的 Topgit 分 文 的 信息 。 用 法 如 
下 


tg[...]info[NAME] 


其 中 NAME 是 可 选 的 Topgit 分 文 名 。 例 如 执行 下 面 的 命令 会 显示 


分 支 t/feature3 的 信息 : 


$tg info 

Topic Branch:t/feature3(1/1 commit) 
Subject: [PATCH]t/feature3 
Base:0fa79a5 

Depends:t/feature1 

t/feature2 

Up-to-date. 


切换 到 tfeaturel 分 支 ， 做 一 些 修改 并 提交 : 


$git checkout t/featurel1 

$echo Hi>hacks.txt 

$git add hacks.txt 

$git commit-m "hacks in t/featureli." 


然后 再 来 看 t/feature3 的 状态 : 


$tg info t/feature3 

Topic Branch:t/feature3(1/1 commit) 
Subject: [PATCH]t/feature3 
Base:ofa79a5 

Depends:t/feature1 

t/feature2 

Needs update from: 

t/feature1(1/1 commit) 


状态 信息 显示 t/feature3 不 再 是 最 新 的 状态 (Up-to-date) ， 因 为 依 
赖 的 Vfeaturel 分 支 包 含 新 的 提交 ， 而 需要 从 t/featurel 获 取 更 新 。 


4.tg update 命 令 


tgupdate 命 令 用 于 更 新 分 文 ， 即 从 依赖 的 分 文 获取 最 新 的 提 区 合 
并 到 当前 分 支 。 同 时 在 refs/top-bases/ 命 名 空间 下 的 特性 分 支 的 基准 
文 也 会 更 新 。 


> 


tg[...]update[NAME] 


其 中 NAME 是 可 选 的 Topgit 分 支 名 。 下 面 就 对 需要 更 新 的 t/feature3 


分 支 执行 tg update 命 令 。 


$git checkout t/feature3 

$tg update 

tg:Updating base with t/featureli1 changes... 
Merge made by recursive. 

hacks.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 featurel1 


tg:Updating t/feature3 against new base... 
Merge made by recursive., 

hacks.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 featurel1 


从 上 面 的 输出 信息 可 以 看 出 执行 了 两 次 分 文 合 并 操作 ， 一 次 是 针 
对 refs/top-bases/t/feature33 引 用 指 问 的 特性 分 支 的 基准 分 支 ， 男 外 一 次 
针对 的 是 refs/heads/t/feature3 特 性 分 支 。 


执行 tg update 命 令 因 为 要 涉及 分 文 的 合并 ， 因 此 并 非 每 次 都 会 成 
功 。 例 如 在 t/feature3 和 t/featurel 中 同时 对 同一 个 文件 (如 hacks.txt) 进 
行 修改 。 然 后 在 Vfeature3 中 再 执行 tg update 可 能 就 会 报错 ， 进 入 冲突 解 
决 状态 。 


$tg update t/feature3 

tg:Updating base with t/featurei1 changes... 

Merge made by recursive， 

hacks.txt|1+ 

1 files changed,1 insertions(+),0 deletions(-) 

tg:Updating t/feature3 against new base... 

Auto-merging hacks.txt 

CONFLICT(content):Merge conflict in hacks.txt 

Automatic merge failed; fix conflicts and then commit the 
result. 

tg:Please commit merge resolution.No need to do anything else 

tg:You can abort this operation usinggit reset--hardnow 

tg:and retry this merge later usingtg update. 


可 以 看 出 第 一 次 对 refs/top-bases/t/feature3 引 用 指 癌 的 特性 分 支 的 
基准 分 支 合并 成 功 ， 但 对 vfeature3 特 性 分 支 进 行 的 合并 出 错 了 。 


执行 tg info 命 令 碍 看 一 下 当前 分 文 Ufeature3 的 状态 。 


$tg info 

Topic Branch:t/feature3(3/2 commits) 

Subject: [PATCH]t/feature3 

Base:37dcb62 

*Base is newer than head!Please run 'tg update'. 
Depends:t/feature1 

t/feature2 

Up-to-date. 


从 上 面 芭 info 命 令 的 输出 可 以 看 出 当前 分 文 的 状态 是 Up-to-date， 
但 是 输出 中 包含 一 个 提示 : 分 文 的 基 (Base) 要 比 头 〈Head) 新 ， 请 


执行 tg update 命 令 。 


这 时 如 果 执 行 tg summary 命 令 的 话 ， 可 以 看 到 UVfeature3 处 于 B 
(Break) 状态 。 


$tg summary 
t/feature1i[PATCH]t/feature1 

0 t/feature2[PATCH]t/feature2 
>B t/feature3[PATCH]t/feature3 


执行 git status 命 令 ， 可 以 看 出 因为 两 个 分 支 同时 修改 了 文件 
hacks.txt 而 导致 名 突 。 


$git status 

#0n branch t/feature3 

#Unmerged paths: 

#(USe "git add/rm<file>..." as appropriate to mark resolution) 
# 

#both modified:hacks.txt 

# 


no changes added to commit(use "git add" and/or "git commit-a") 


可 以 编辑 hacks.txt 文 件 ， 或 者 调用 冲突 解决 工具 解决 冲突 ， 之 后 

再 提交 ， 这 才 真 正 完 成 了 此 次 tg update 。 

$git mergetool 

$git commit-m "resolved conflict with t/featureli." 

$tg info 

Topic Branch:t/feature3(4/2 commits) 

Subject: [PATCH]t/feature3 

Base:37dcb62 

Depends:t/feature1 


t/feature2 
Up-to-date. 


5.tg summary 命 令 


tg summary 命 令 用 于 显示 Topgit 管 理 的 特性 分 文 的 列表 及 各 个 分 文 
的 状态 。 用 法 如 下 : 


tg[...]summary[-t|--sort|--deps|--graphviz] 


不 带 任何 参数 执行 tg summary 是 最 常用 的 Topgit 命 令 。 在 介绍 不 市 
参数 的 tg summary 命 令 之 前 ， 先 看 看 该 命令 的 其 他 用 法 。 


使 用 -t 参 数 显示 特性 分 文 列表 。 


S tq summary -七 
t/featurel 
t/feature2 
t/feature3 


使 用 --deps 参数 除了 显示 Topgit 特性 分 支 外 ， 还 会 显示 特性 分 支 的 依赖 分 支 。 


$$ tg summary -~-deps 
t/featurel master 
t/feature2 master 
t/feature3 t/featurel 
t/feature3 t/featurez2 


使 用 -~sort 参数 按照 分 支 依赖 的 顺序 显示 分 支 列表 ， 除 了 显示 Topgit 分 支 外 ， 还 会 显 
示 依 赖 的 非 Topgit 分 支 。 


$s tq summary --sort 
t/feature3 
t/feature2 
t/featurel 

master 


使 用 ~-graphviz 会 输出 GraphViz 格式 文件 ， 可 以 用 于 显示 特性 分 支 之 间 的 关系 。 
$§ tg summary -~-graphviz | dot -~-T png ~o topgit.png 


生成 的 特性 分 支 关系 图 如 图 22-4 所 示 。 


TopGit Layout 


图 22-4 Topgit 特性 分 支 依 环 关系 图 
不 带 任何 参数 执行 tg summary 显示 分 支 列表 及 状态 。 这 是 最 常用 的 Topgit 命令 之 一 。 


$ tg summary 


t/featurel [PATCH] t/featurel 
0 t/feature2 [PATCH] t/feature2 
> t/feature3 [PATCH] t/feature: 


其 中 : 

口 标识 “>”: (t/feature3 分 支 之 前 的 大 于 号 ) 用 于 标记 当前 所 处 的 特性 分 支 。 

口 标记 “0”, (t/featurez 分 支 前 的 数字 0) 含义 是 该 分 支 中 没有 提交 ， 这 是 一 个 建 
并 后 尚未 使 用 或 废弃 的 分 支 。 


标记 "D": 表明 该 分 文 处 于 过 时 (out-of-date) 状态 。 可 能 是 一 个 
或 多 个 依赖 的 分 文 包 售 了 新 的 提交 ， 尚 未 合并 到 此 特性 分 文 。 可 以 用 
tg info 命 令 看 出 到 撒 是 由 于 哪个 依赖 分 文 的 改动 导致 该 特性 分 文 处 于 
过 时 状态 。 


标记 "B": 之 前 演示 中 出 现 过 ， 表 明 该 分 文 处 于 Break 状 态 ， 即 可 
能 由 于 冲突 未 解决 或 其 他 原因 导致 该 特性 分 文 的 基准 分 文 (base) 相 
对 该 分 文 的 头 (head) 不 匹配 。 例 如 refs/top-bases 下 的 特性 分 支 的 基准 
分 文 迁移 了 ， 但 是 特性 分 文 未 完成 迁移 。 


标记 “1”， 表明 该 特性 分 文 所 依赖 的 分 文 不 存在 。 


标记 "1": 表明 该 特性 分 文 只 存在 于 本 地 ， 不 存在 于 远程 跟踪 服务 


标记 "r": 表明 该 特性 分 文 既 存在 于 本 地 ， 又 存在 于 远程 跟 踩 服务 
郁 ， 并 且 两 者 匹配 。 


标记 "L": 表明 该 特性 分 文 ， 本 地 的 比 远程 跟踪 服务 器 的 新 。 


标记 "R": 表明 该 特性 分 文 ， 远 程 跟 蹊 服务 套 的 比 本 地 的 新 。 


如 果 没 有 出 现 "Wr/L/R": 表明 该 版 本 库 尚 未 设置 远程 版 本 库 。 


一 般 这 有 标记 "rm" 的 古 最 常见 的 ， 也 十 最 正常 的 。 


下 面 要 介绍 的 tg remote 命 令 为 测试 版 本 库 建立 一 个 对 应 的 远程 版 
本 库 ， 然 后 天 能 在 tg summary 的 输出 中 看 到 "TVYLVR" 等 标识 符 了 。 


6.tg remote 命 令 


tg remote 命 令 用 于 为 远程 版 本 库 增 加 Topgit 的 相关 设置 ， 以 便 在 和 
该 远程 版 本 库 进 行 git fetch、git pull 等 操作 时 能 够 同步 Topgit 的 相关 分 
文 。 命 令 用 法 如 下 : 


tg[...Jjremote[--populate][REMOTE] 


其 中 REMOTE 为 远程 版 本 库 的 名 称 ， 默 认为 origin。 执 行 tg remote 
命令 会 目 动 在 版 本 的 配置 文件 中 增加 的 refs/top-bases 下 引用 同步 表达 
式 。 下 面 的 示例 中 的 最 后 一 行 就 是 执行 tg remote origin 后 增加 的 设置 。 


[remote "origin"] 

url=/path/to/repos/tgtest.git 
fetch=+refs/heads/*:refs/remotes/origin/* 
fetch=+refs/top-bases/*:refs/remotes/origin/top-bases/* 


如 宁 使 用 --populate 参 数 ， 除 了 会 同上 面 那样 设置 默认 的 Topgit 远 
程 版 本 库 外 ， 还 会 自动 执行 git fetch 命 令 ， 然 后 在 本 地 建立 Topgit 特 性 
分 文 和 对 应 的 基准 分 文 。 


当 执行 tg 命令 时 ， 如 果 不 用 -r remote 全 局 参数 ， 则 默认 使 用 origin 
远程 版 本 库 。 


下 面 为 前 面 测试 的 Topgit 版 本 库 设 置 一 个 远程 版 本 库 ， 有 具体 操作 
过 程 如 下 。 


(1) 先 创建 一 个 裸 版 本 库 tgtest.git 。 


$git init--bare/path/to/repos/tgtest.git 
Initialized empty Git repository in/path/to/repos/tgtest.git/ 


(2) 然后 执行 git remote 命 令 ， 将 刚刚 创建 的 版 本 库 以 origin 为 名 
注册 为 远程 版 本 库 。 


$git remote add origin/path/to/repos/tgtest.git 


(3) 执行 git push， 将 当前 版 本 库 的 master 分 支 推送 到 刚刚 创建 的 
远程 版 本 库 。 


$git push origin master 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(3/3),done. 
Writing objects:100%(7/7),585 bytes, done. 
Total 7(delta 0),reused 0O(delta 0) 
Unpacking objects:100%(7/7),done. 
To/path/to/repos/tgtest.git 

*[new branch]master-~>master 


(4) 之 后 运行 tg remote 命 令 为 远程 版 本 库 添加 额外 的 配置 ， 以 便 
该 远程 版 本 库 色 E 够 跟踪 Topgit 分 支 3 


$tg remote--populate origin 


(5) 执行 了 上 面 的 tg remote 命 令 后 ， 会 在 当前 版 本 库 的 .giVconfig 
文件 中 添加 设置 (以 加 号 开头 的 行 ) 


[remote "origin"] 

url=/path/to/repos/tgtest.git 
fetch=+refs/heads/*:refs/remotes/origin/* 

+ 
fetch=+refs/top-bases/*:refs/remotes/origin/top-bases/* 
+[topgit] 

+remote=origin 


(6) 这 时 再 执行 tg summary 会 看 到 分 文 前 面 都 有 标记 "1]"， 即 本 地 
提交 比 远程 版 本 库 的 新 。 


$tg summary 

1 t/feature1i[PATCH]t/feature1 
O01 t/feature2[PATCH]t/feature2 
>1 t/feature3[PATCH]t/feature3 


(7) 执行 tg push 命 令 将 特性 分 支 Wfeature2 及 其 基准 分 支 推 送 到 远 
程 版 本 库 。 


$tg push t/feature2 

Counting objects:5, done. 

Delta compression using up to 2 threads. 

Compressing objects:100%(3/3),done. 

Writing objects:100%(4/4),457 bytes, done. 

Total 4(delta 0),reused 0O(delta 0) 

Unpacking objects:100%(4/4),done. 

To/path/to/repos/tgtest.git 

*[new branch]t/feature2->t/feature2 

*[new branch]refs/top-bases/t/feature2-~>refs/top- 
bases/t/feature2 


(8) 再 来 看 看 tg summary 的 输出 ， 会 看 到 t/feature2 的 标识 变 
为 "r"， 即 远程 和 本 地 同步 。 
$tg Summary 
1 t/feature1i[PATCH]t/feature1 


or t/feature2[PATCH]t/feature2 
>1 t/feature3[PATCH]t/feature3 


(9) 运行 tg push--all 1 ， 会 将 所 有 的 Topgit 分 支 推送 到 远程 版 本 
库 。 之 后 再 来 看 tg summary 的 输出 ， 会 看 到 所 有 分 文 都 带 上 了 "的 标 


识 。 


AAA 


$tg push--all 


$tg Summary 

r t/feature1i[PATCH]t/feature1 
or t/feature2[PATCH]t/feature2 
>r t/feature3[PATCH]t/feature3 


如 果 版 本 库 设置 了 多 个 远程 版 本 库 ， 要 针对 每 一 个 远程 版 本 库 执 
行 tg remote <REMOTE>>， 但 只 能 有 一 个 远程 的 源 用 --populate 参 数 调 
用 tg remote 将 其 设置 为 默认 的 远程 版 本 库 。 


7.tg push 命 令 


在 前 面 tg remote 的 介绍 中 ， 已 经 看 到 过 tg push 命 令 。tg push 命 令 
用 于 将 Topgit 特 性 分 文 及 对 应 的 基准 分 文 推送 到 远程 版 本 库 。 用 法 如 
下 : 


tg[..,]push[--dry-run][--no-deps][L--tgish-only][L--alllpbpranch*] 


tg push 命 令 后 面 的 参数 指定 要 推送 给 远程 服务 硕 的 分 文 列 表 ， 如 
果 省 略 则 推送 当前 分 支 。 改 进 的 tg push 命 令 文 持 通过 --all 参 数 将 所 有 
Topgit 特 性 分 文 推送 到 远程 版 本 库 。 


参数 --dry-run 用 于 测试 推送 的 执行 效果 ， 而 不 古 真 正 执 行 。 参 数 -- 
no-deps 的 含义 是 不 推送 依赖 的 分 文 ， 默 认 推 送 。 参 数 --tgish-only 的 合 
义 征 只 推送 Topgit 特 性 分 文 ， 黑 认 推 送 指定 的 所 有 分 文 。 


8.tg depend 命 令 


tg depend 命 令 目 前 仅 实现 了 为 当前 的 Topgit 特 性 分 文 增加 新 的 依 
赖 。 用 法 如 下 : 


tg[...]depend add NAME 


将 NAME 加 入 到 文件 .topdeps 中 ， 并 将 NAME 分 文 癌 该 特性 分 文 及 
特性 分 文 的 基准 分 文 进行 合并 操作 。 虽 然 Topgit 可 以 检查 到 分 文 的 循 
环 依赖 ， 但 还 是 要 注意 合理 地 设置 分 文 的 依赖 ， 合 并 重复 的 依赖 。 


9.tg base 命 令 


tg base 命 令 用 于 显示 特性 分 支 的 基准 分 支 的 提交 ID (精简 格 
3 


10.tg delete 命 令 


tg delete 命 令 用 于 删除 Topgit 特 性 分 文 及 其 对 应 的 基准 分 文 。 用 法 
如 下 : 


tg[..,]delete[-f]NAME 


难 认 只 删除 没有 改动 的 分 文 ， 即 标记 为 “0 的 分 文 ， 除 非 使 用 -{ 参 


目前 此 命令 尚 不 能 目 动 清除 其 分 文中 对 删除 分 文 的 依赖 ， 还 需要 
手工 调整 .topdeps 文 件 ， 删 除 对 不 存在 的 分 支 的 依赖 。 


11.tg patch 命 令 


tg Patch 命令 通 过 比较 特性 分 文 及 其 基准 分 文 的 过 异 ， 显 示 该 特性 
分 文 的 补丁。 用 法 如 下 : 


tg[..,]patch[-I|-w]LNAME] 


其 中 -ji 参 数 显 示 和 暂 存 区 和 基准 分 文 的 差异 。-w 人 参数 显示 工作 区 和 


tg patch 命 令 存在 的 一 个 问题 是 只 能 正确 显示 工作 区 中 的 根 执行 。 
这 个 缺陷 已 经 在 我 改进 的 Topgit 中 被 改正 [2 。 


12.tg export 命 令 


tg export 命 令 用 于 导出 特性 分 支 及 其 依赖 ， 便 于 同上 游 页 献 。 可 
以 导出 Quilt 格 式 的 补丁 列表 ， 或 者 顺序 提交 到 另外 的 分 文中 。 用 法 如 
下 : 


tg[...Jexport([--collapse]NEWBRANCH|[--all|-b 
BRANCH1, BRANCH2...]--quilt DIRECTORY|--linearize NEWBRANCH) 


这 个 命令 有 三 种 导出 方法 。 
将 所 有 的 Topgit 特 性 分 支 压缩 为 一 个 ， 提 交 到 新 的 分 支 。 
tg[...Jexport--collapse NEWBRAQNCH 

将 所 有 的 Topgit 竺 性 分 支 按照 线性 顺序 提交 到 一 个 新 的 分 支 中 。 


tg[...J]export--linearize NEWBRANCH 


将 指定 的 Topgit 分 文 (一 个 或 多 个 ) 及 其 依赖 分 支 转换 为 Quilt 格 
式 的 补丁 ， 保 存 到 指定 目 永 中 。 


tg[...Jexport-b BRANCH1, BRANCH2...--quilt DIRECTORY 


在 导出 为 Quilt 格 式 补 丁 的 时 候 ， 如 有 果 想 将 所 有 的 分 文 寻 出， 必须 
用 -b 人 参数 将 分 文 全 部 罗列 《或 者 分 文 的 依赖 关系 将 所 有 分 文 吉 括 ) ， 


这 对 于 需要 导出 所 有 分 文 的 操作 非常 不 方便 。 我 改进 的 Topgit 通 过 --all 
参数 实现 了 所 有 分 文 的 导出 。 


13.tg import 命 令 


tg import 命 令 将 分 文 的 提交 转换 为 Topgit 特 性 分 文 ， 指 定 范围 的 每 
个 提交 都 转换 为 一 个 特性 分 文 ， 各 个 特性 分 文 之 间 线 性 依赖 。 用 法 如 
R 


tg[...]import[-d BASE_ BRANCH]{[-p PREFIX]RANGE...|-s NAME 
COMMIT} 


如 宁 不 使 用 -d 参 数 ， 特 性 分 文 则 以 当前 分 文 为 依赖 。 特 性 分 文 名 
称 目 动 生成 ， 使 用 约定 俗 成 的 WV 作为 前 约 ， 也 可 以 通过 -p 参 数 指定 其 他 


前 级 。 可 以 通过 -s 参 数 设 定 特性 分 支 的 名 称 。 
14.tg log 命 令 
tg log 命 令 显示 特性 分 文 的 提交 历史 ， 并 忽略 合并 引入 的 提交 。 
tg[...]log[NAME][--GIT LOG OPTIONS...] 


tg log 命 令 实际 是 对 git log 命 令 的 封 狼 。 这 个 命令 通过 --no-merges 


和 --frst-parent 参 数 调 用 git log， 昌 然 屏 严 了 大 量 因 和 依赖 分 支 合并 而 引 


入 的 依赖 分 文 的 提交 日 志 ， 但 是 同时 也 屏 菩 了 合并 到 该 特性 分 文 的 其 
他 页 献 者 的 提交 。 


15.tg mail 命 令 


tmail 命 令 将 当前 分 文 或 指定 特性 分 文 的 补丁 以 邮件 的 形式 外 
发 。 用 法 如 下 : 


tg[...]Jmail[-s SEND_EMAIL_ARGS][-r REFERENCE_MSGID][NAME] 


tg mail 调 用 git send-email 发 送 邮件 ， 参 数 -s 用 于 向 该 命令 传递 参数 
(需要 用 双 引 号 括 起 来 ) 。 邮 件 中 的 目的 地 址 从 补丁 文件 头 中 的 To、 
Cc 和 Bcc 等 字段 获取 。 参 数 -r 引 用 回复 邮件 的 ID 以 便 正 确 地 生成 in- 
reply-to 邮 件 头 。 


注意 : 此 命令 可 能 会 发 送 多 封 邮 件 ， 可 以 通过 如 下 设置 在 调用 git 
send-email 命 令 发 送 邮件 时 进行 确认 。 


$git config sendemail.confrm always 
16.tg files 命 令 
tg files 命 令 用 于 显示 当前 或 指定 的 特性 分 文 改 动 了 哪些 文件 。 


17.tg prev 命 令 


tg prev 命 令 用 于 显示 当前 或 指定 的 特性 分 文 所 依赖 的 分 文 名 。 


tg next 命 令 用 于 显示 当前 或 指定 的 特性 分 文 被 其 他 哪些 特性 分 文 
所 依赖 。 


19.tg graph 命 令 


tg graph 命 令 并 非 官方 提供 的 命令 ， 而 是 源 自 一 个 补丁 器 ， 实 现 
文本 方式 的 Topgit 分 支 图 。 当 然 这 个 文本 分 支 图 没有 tg summary-- 
graphviz 生 成 的 那么 漂亮 。 


[1] 改进 后 的 Topgit 才 提供 同步 全 部 特性 分 支 的 功能 。 

[2] 最 新 的 Topgit 重 构 了 tg-push 的 代码 ， 改 正 了 这 个 缺陷 ， 所 以 会 看 到 
最 新 改进 版 的 Topgit 该 特性 分 支 为 空 。 

[3] http://kerneltrap.org/mailarchive/git/2009/5/20/2922 


22.5 ”用 Topgit 方 式 改造 Topgit 


在 Topgit 的 使 用 中 陆续 发 现 了 一 些 不 合用 的 地 方 ， 于 古 便 以 Topgit 
特性 分 文 的 方式 来 对 Topgit 进 行 改 造 。 在 群英 汇 的 博客 上 介绍 了 如 下 
J 


TopGit 改 进 (1) : tg push 全 部 分 支书 
TopGit 改 进 (2) : tg 导出 全 部 分 支 
TopGit 改 进 (3) : 更 灵活 的 tg patch 3 
TopGit 改 进 (4) : tg 命令 补 齐 号 
TopGit 改 进 (5) : tg summary 执 行 的 更 快 5 


下 面 就 以 Topgit 改 造 过 程 为 例 ， 来 介绍 如 何 参与 一 个 Topgit 管 理 下 
的 项 目的 开发 。 改 造 后 的 Topgit 版 本 库 地 址 为 :git://github.com/ossxp- 


com/topgit.git ° 
首先 克隆 该 版 本 库 : 


$git clone git://github.com/ossxp-com/topgit.git 
$cd topgit 


| 叶 


看 远程 分 文 : 


$git branch-r 

origin/HEAD- >origin/master 
origin/master 
origin/t/debian_ locations 
origin/t/export_quilt_ all 
origin/t/fast_tg_summary 
origin/t/graphviz_layout 
origin/t/tg_completion_bugfix 
origin/t/tg_graph_ascii output 
origin/t/tg_patch_cdup 
origin/t/tg_push_all 
origin/tgmaster 


看 到 远程 分 支 中 出 现 了 熟悉 的 以 t/ 为 前 级 的 Topgit 分 支 ， 说 明 这 个 
版 本 库 是 一 个 由 Topgit 进 行 管理 的 版 本 库 。 为 了 能 够 获取 Topgit 各 个 特 
性 分 支 的 基准 分 支 ， 需 要 用 tg remote 命 令 对 默认 的 origin 远 程 版 本 库 注 
山王 下 


$tg remote--populate origin 

tg:Remote origin can now follow TopGit topic branches. 
tg:Populating local topic branches from remote'origin'... 
From git://github.com/ossxp-com/topgit 

*[new branch]refs/top-bases/t/debian_ locations-> 
origin/top-bases/t/debian_ locations 

*[new branch]refs/top-bases/t/export_quilt all-> 
origin/top-bases/t/export_quilt _ all 

*[new branch]refs/top-bases/t/fast_tg_summary-> 
origin/top-bases/t/fast_tg_summary 

*[new branch]refs/top-bases/t/graphviz_layout-> 
origin/top-bases/t/graphviz_layout 

*[new branch]refs/top-bases/t/tg_completion_ bugfix-> 
origin/top-bases/t/tg_ completion_ bugfix 

*[new branch]refs/top-bases/t/tg_graph_ascii output-> 
origin/top-bases/t/tg_ graph_ascii output 

*[new branch]refs/top-bases/t/tg_patch_cdup-> 
origin/top-bases/t/tg_patch_cdup 

*[new branch]refs/top-bases/t/tg_push all-> 


origin/top-bases/t/tg_push_all 
tg:Adding branch t/debian_locations... 
tg:Adding branch t/export_quilt all... 
tg:Adding branch t/fast_tg_summary... 
tg:Adding branch t/graphviz_layout. 
tg:Adding branch t/tg _ completion_ bugfix.. 
tg:Adding branch t/tg_graph_ascii output.. 
tg:Adding branch t/tg_patch_cdup... 
tg:Adding branch t/tg_push all... 
tg:The remote'origin'is now the default source of topic 
branches. 


执行 tg summary 查 看 一 下 本 地 Topgit 特 性 的 分 支 状态 。 


$tg summary 

rit/debian_locations[PATCH]make file locations Debian-compatible 
rit/export_quilt _ all[PATCH]t/export_quilt all 
rit/fast_tg_summary[PATCH]t/fast_tg_summary 
rit/graphviz_layout[PATCH]t/graphviz_layout 

rit/tg _completion bugfix[PATCH]t/tg_completion_bugfix 

r t/tg_graph_ascii output[PATCH]t/tg_graph_ascii output 
rit/tg_patch_cdup[PATCH]t/tg_patch_cdup 
rit/tg_push_all[PATCH]t/tg_push _all 


怎么 ? 出 现 了 感叹号 ?记得 前 面 在 介 绍 tg summary 命 令 令 的 章 市 中 
提 到 过 ， 感 到 号 的 出 现 说 明 该 特性 分 支 所 依赖 的 分 支 丢 失 了 。 用 tg 
info 查 看 一 下 其 中 的 某 个 特性 分 支 。 


$tg info t/export_quilt _ all 

Topic Branch:t/export_quilt_all(6/4 commits ) 
Subject: [PATCH]t/export_quilt_all 
Base:8bof1f9 

Remote Mate:origin/t/export_quilt_all 
Depends:tgmaster 

MISSING: tgmaster 

Up-to-date. 


原来 该 特性 分 文 依赖 tgmaster 分 文 ， 而 不 是 master 分 文 。 远 程 存在 


tgmaster 分 


支 而 本 地 尚 不 存在 。 于 是 在 本 地 建立 tgmaster 跟踪 分 支 。 


8 git checkout tqgmaster ” 
Branch taqmaster set up to track remote branch tagmaster from origin. 
Switched to a new branch ‘tgmaster 


这 回 tg summary 的 输出 正常 了 。 


$ tg Summary 
人 t/debian locations [PATCH] make file locations Debian-compatible 
党 t/export quilt all [PATCH] t/export quilt all 
r t/fast tg summary [PATCH] 上 /East tg summary 
E t/graphviz layout {PATCH] t/graphviz layout 
轩 t/tg completion bugftix [PATCH] t/tg completion bugtfix 
r t/tg graph ascii output {PATCH] t/tg graph ascii output 
和 t/tg patch cdup [PATCH] t/tg patch cdup 
r t/tg push all {PATCH] t/tg push all 


遂 过 下 面 的 命令 创建 图 形 化 的 分 支 图 。 


$ tg summary ~-graphviz | dot -T png ~ topgit.png 


生成 的 特性 分 支 关系 图 如 图 22-5 所 示 。 
TopGit Layout 


t/debian locations 


Uexport_quilt_all 


Vfast_tg_summary Utg graph ascii output 
tigraphviz layout 


titg_completion bugfix 
ttg_patch cdup 


t/tg_push all 


22-5 Topgit 改进 项 目的 特性 分 支 依 籁 关系 图 


其 中 : 


特性 分 支 t/export_guilt_all， 为 tg export--quilt 命 令 增 加 --all 选 项 ， 
以 便 导 出 所 有 的 特性 分 文 。 


特性 分 文 Ufast_tg_summary， 主 要 是 改进 tg 命 令 补 齐 时 分 文 的 显示 
速度 ， 当 特性 分 文 接近 上 百 个 时 差异 非常 明显 。 


特性 分 文 UVgraphviz_layout， 改 进 了 分 文 的 图 形 输 出 格式 。 
特性 分 文 Utg_completion_bugfix ， 解 决 了 命令 补 齐 的 一 个 Bug。 


特性 分 文 UVtg_graph_ascii output， 源 目 Bert Wesarg 的 页 献 ， 非 常 巧 
妙 地 实现 了 文本 化 的 分 文 图 显示 ， 展 示 了 gvpr 命 令 的 强大 功能 。 


特性 分 文 Vtg_patch_cdup， 解 决 了 在 项 目的 子 目 录 下 无 法 执行 tg 
patch 的 问题 。 


特性 分 支 Vtg_push_all， 通 过 为 tg push 增 加 --all 选 项 ， 解 决 了 当 tg 
从 0.7 版 升级 到 0.8 了 版 后 ， 无 法 批量 向 上 游 推送 特性 分 文 的 问题 。 


下 面 展示 一 下 如 何 跟踪 上 游 的 最 新 改动 ， 并 迁移 到 新 的 上 游 版 
本 。 分 文 tgmaster 用 于 跟踪 上 游 的 Topgit 分 支 ， 以 t/ 开 头 的 分 支 古 对 
Topgit 改 进 的 特性 分 文 ， 而 master 分 文 实 际 上 十 导出 Topgit 让 本 文件 并 
人 负责 编译 特定 Linux 平 台 发 行 包 的 分 文 。 具 体操 作 过 程 如 下 : 


(1) 把 官方 的 Topgit 版 本 库 以 upstream 的 名 称 加 入 作为 新 的 远程 
版 本 库 。 


$git remote add upstream git://repo.or.cz/topgit.git 


(2) 然后 将 upstream 远 程 版 本 的 master 分 支 合并 到 本 地 的 tgmaster 
Sy 
$git pull upstream master:tgmaster 


From git://repo.or.cz/topgit 
29ab4cf. .8b0of1f9 master-~>tgmaster 


(3) 此 时 再 执行 tg summary 会 发 现 所 有 的 Topgit 分 支 都 多 了 一 个 
标记 D， 表 明 因 为 依赖 分 文 的 更 新 而 导致 Topgit 特 性 分 文 过 时 了 。 


$tg Summary 

r D t/debian locations[PATCH]make file locations Debian- 
compatible 

r D t/export_quilt _ all[fPATCH]t/export_ quilt all 


r D t/fast_ tg_ summary[PATCH]t/fast_tg_ summary 

r D t/graphviz layout[PATCH]t/graphviz_layout 

r D t/tg completion _ bugfix[PATCH]t/tg_completion_ bugfix 

r D t/tg graph ascii output[PATCH]t/tg_graph_ascii output 

r D t/tg patch cdup[PATCH]t/tg_patch_cdup 

r D t/tg push_all[fPATCH]t/tg_push_all 

(4) 依次 对 各 个 分 支 执行 tg update， 完 成 对 更 新 的 依赖 分 支 的 合 

并 o 


$tg Update t/export_quilt_all 


(5) 对 各 个 分 文 完 成 更 新 后 ， 会 发 现 tg summary 的 输出 中 ， 标 识 

过 时 的 DD 标记 变 为 L， 即 本 地 比 远程 服务 器 分 支 要 新 。 

$tg summary 

rL t/debian locations[PATCH]make file locations Debian- 
compatible 

rL t/export_quilt all[PATCH]t/export_quilt_all 

rL t/fast_ tg_summary[PATCH]t/fast_tg_summary 

rL t/graphviz_layout[PATCH]t/graphviz_layout 

rL t/tg _ completion_ bugfix[PATCH]t/tg_completion bugfix 

rL t/tg graph_ascii_ output[PATCH]t/tg_graph_ascii output 


rL t/tg_patch_ cdup[PATCH]t/tg_patch_cdup 
rL t/tg_push_all[PATCH]t/tg_push_all 


(6) 执行 tg push--all 束 可 以 实现 将 所 有 的 Topgit 特 性 分 支 推 送 到 
远程 服务 右上 ， 当 然 需 要 有 提交 权限 才 可 以 。 


[1| http://blog.ossxp.com/2010/01/247/ 
[2] http://blog.ossxp.com/2010/01/255/ 
[3] http://blog.ossxp.com/2010/01/257/ 
[4] http://blog.ossxp.com/2010/01/259/ 
[5] http://blog.ossxp.com/2010/01/261/ 


22.6 ”Topgit 使 用 中 的 注意 事项 


1. 经 常 运行 tg remote--populate 获 取 他 人 创建 的 特性 分 文 


运行 命令 git fetch 或 命令 git pull 和 远程 版 本 库 同步 ， 只 能 将 他 人 创 
建 的 Topgit 特 性 分 文 在 本 地 以 远程 分 文 (refs/remotes/origin/t/ < branch- 
name> 之 ) 的 方式 保存 ， 而 不 能 自动 在 本 地 建立 分 文 。 


如 果 确 认 版 本 库 是 使 用 Topgit 维 护 的 话 ， 应 该 在 和 远程 版 本 库 同 


步 的 时 候 执行 tg remote--populate origin。 这 条 命令 会 做 两 件 事情 : 
自动 调用 git fetch origin 获 取 远 程 origin 版 本 库 的 新 的 提交 和 引用 。 


分 查 refs/remotes/origin/top-bases/ 下 的 所 有 引用 ， 如 果 是 新 的 ， 在 
本 地 (refs/top-bases/) 尚 不 存在 ， 说 明 有 其 他 人 创建 了 新 的 特性 分 
文 。Topgit 会 据 此 上 自动 在 本 地 创建 新 的 特性 分 文 。 


2. 适 时 地 调整 特性 分 文 的 依赖 关系 


例如 之 前 用 于 Topgit 演 示 的 版 本 库 ， 各 个 特性 分 文 的 依赖 文件 内 
容 如 下 。 


分 支 t/feature1 的 .topdeps 文 件 


master 


分 文 Ufeature2 的 .topdeps 文 件 


master 


分 支 t/feature3 的 .topdeps 文 件 


t/featurel1 
t/feature2 


如 果 分 支 t/feature3 的 .topdeps 文 件 是 这 样 的 ， 可 能 就 会 存在 问题 。 


master 
t/featurel1 
t/feature2 


问题 在 于 Wfeature3 依 赖 的 其 他 分 文 已 经 依赖 了 master 分 文 ， 虽然 不 
会 造成 致命 的 影响 ， 但 是 在 特定 情况 下 这 种 重复 会 造成 不 便 。 例 如 在 
master 分 文 更 新 后 ， 可 能 由 于 代码 重 构 的 比较 历 害 ， 在 特性 分 支 迁 移 
时 会 造成 冲突 ， 如 在 tfeature1l 分 文中 执行 tg update 会 过 到 冲突 ， 当 入 百 
完成 冲突 解决 并 提交 后 ， 在 tfeature3 中 执行 tg update 会 因为 先 依赖 的 是 
master 分 支 ， 所 以 先 在 master 分 支 上 对 t/feature3 分 支 进 行 合并 ， 这 样 就 
肯定 会 遇 到 和 tfeaturel 相 同 的 冲突 ， 还 要 表 重 复 解 决 一 次 。 


如 果 在 .topdeps 文 件 中 删除 了 对 master 分 支 的 重复 的 依赖 ， 就 不 会 
出 现 上 面 的 重复 解决 冲突 的 问题 了 。 


同样 的 道理 ， 如 果 tfeature3 的 .topdeps 文 件 写成 这 样 ， 戏 果 也 将 不 
同 : 


t/feature2 
t/featurel1 


依赖 的 顺序 不 同 会 造成 合并 的 顺序 也 不 同 ， 同 样 也 会 产生 重复 的 
冲突 解决 。 因 此 当 发 现 重 复 的 冲突 时 ， 可 以 取消 合并 操作 ， 修 改 特性 
分 文 的 .topdeps 文 件 ， 调 整 文件 内 容 (删除 重复 分 文 ， 调整 分 支 顺 序 ) 
并 提交 ， 然 后 再 执行 tg update 继 续 合并 操作 。 


3.Iopgit 特 性 分 文 的 里 程 碑 和 分 文 管理 


Topgit 本 喘 吏 是 管理 特性 分 文 的 软件 。Topgit 肝 个 时 刻 的 开发 状态 
是 Topgit 管 理 下 的 所 有 分 文 〈 包 括 基准 分 支 ) 整体 的 状态 。 思 考 一 
下 : 能 够 用 里 程 碑 来 标记 Topgit 管 理 的 版 本 库 的 开发 状态 吗 ? 


使 用 里 程 碑 来 管理 是 不 可 能 的 ， 因 为 Git 里 程 牧 只 能 针对 一 个 分 文 
做 标记 而 不 能 标记 所 有 的 分 文 。 使 用 克隆 是 唯一 的 方法 。 殉 隆 不 但 用 
于 标记 Topgit 版 本 库 的 开发 状态 ， 也 可 以 用 于 Topgit 版 本 库 的 分 支管 
理 。 例 如 一 旦 上 游 出 现 新 版 本 ， 束 从 当前 版 本 库 建 立 一 个 克隆 ， 原 来 
的 版 本 库 用 于 维护 原 有 上 游 版 本 的 定制 开发 ， 新 的 克隆 版 本 库 针 对 新 
的 上 游 版 本 进行 迁移 ， 用 于 新 的 上 游 版 本 的 特性 开发 。 


也 许 还 可 以 通过 其 他 方法 实现 ， 例 如 将 Topgit 所 有 相关 的 分 文 都 
复制 到 一 个 特定 的 引用 目 孙 中 或 记录 在 文件 中 ， 以 实现 特性 分 文 的 状 
坊 刘 孙 池 


第 23 革 于 模 组 协同 模型 


项 目的 版 本 库 在 某 些 情况 下 需要 引用 其 他 版 本 库 中 的 文件 ， 例 如 
公司 积 素 了 一 套 币 用 的 函数 库 ， 被 多 个 项 目 调用 ， 显 然 这 个 函数 库 的 
代码 不 能 直接 放 到 肝 个 项 目的 代码 中 ， 而 是 要 独立 为 一 个 代码 库 ， 那 
么 其 他 项 目 有 要 调用 公共 的 函数 库 该 如 何 处 理 昵 ? 分 别 把 公共 男 数 库 的 
文件 找 贝 到 各 目的 项 目 中 会 造成 见 余 ， 丢 弃 了 公共 画 数 库 的 维护 历 
史 ， 这 显然 不 是 好 的 方法 。 本 章 要 讨论 的 子 模 组 协同 模型 ， 就 是 解决 


这 个 问题 的 一 个 方案 。 


底 悉 Subversion 的 用 户 马 上 会 想起 svn:externals 属 性 可 以 实现 对 外 
部 代码 库 的 引用 。Git 的 子 模 组 (submodule) 是 类 似 的 一 种 实现 。 不 
过 因为 Git 的 特殊 性 ， 二 者 的 区 别 还 是 蛮 大 的 ， 参 见 表 23-1 。 


表 23-1 SVYN 和 Git 相似 功能 对 照 表 


gt submodulc 


如 何 记 录 外 部 版 本 库 朋 地址 项 目 根 目录 下 的 .gitmodules 文件 
起 否 

和 i CN 在 使 用 svn checkout 检 出 时 ， 若 使 | 默认 不 克 降 外 部 版 本 库 。 车 要 克 降 则 

由 人 是 Gf 动 ra 外 部 版 本 上 i en , 3 rs 

WANN 1 动 检 出 外 部 版 本 并 用 参数 -~~ignore~externals 可 以 | 用 git submodule init 及 Git 
忽略 对 外 部 版 本 库 的 引用 ， 不 检 出 ubmodule update 命令 

是否 能 部 分 引用 外 部 版 本 库 [ 是 在 

是 否 能 部 分 引用 外 部 版 本 库 内 容 , i 2 NN 

E 耕 能 部 分 引用 外 部 版 本 库 内 容 。 | 因为 SVN 支持 部 分 检 出 必须 克 队 整个 外 部 版 本 库 


1 
是 否 可 以 指向 分 支 而 随 之 政变 a 
攻 否 可 以 指向 分 支 而 随 之 改变 固定 于 外 部 版 本 库 的 其 个 提交 


23.1 创建 子 模 组 


在 演示 子 模 组 的 创建 和 使 用 之 前 ， 先 做 些 准 备 工 作 。 欧 符 试 建立 
两 个 公共 函数 库 〈libA.git 和 libB.gitj) ， 以 及 一 个 引用 函数 库 的 主 版 本 
库 (super.git) 。 

$git--git-dir=/path/to/repos/libA.git init--bare 


$git--git-dir=/path/to/repos/libB.git init--bare 
$git--git-dir=/path/to/repos/super.git init--bare 


癌 两 个 公共 的 函数 库 中 填充 些 数据 。 这 就 需 要 在 工作 区 克隆 两 个 
函数 库 ， 提 区 数 据 并 推送 。 


区 隆 libA.git 版 本 库 ， 诡 加 一 些 数据 ， 然 后 提交 并 推送 。 说 明 : 未 
例 中 显示 为 hack.……. 的 地 方 做 了 一 些 改动 《如 创建 新 文件 等 ) ， 并 将 
改动 添加 到 和 暂 存 区 。 


$git clone/path/to/repos/libA.git/path/to/my/workspace/l1ibA 
$cd/path/to/my/workspace/1ibA 

hack... 

$git commit-m "add data for libA" 

$git push origin master 


克隆 libB.git 版 本 库 ， 添 加 一 些 数据 ， 然 后 提交 并 推送 。 


$git clone/path/to/repos/libB.git/path/to/my/workspace/l1ibB 
$cd/path/to/my/workspace/libB 

hack... 

$git commit-m"add data for libB" 

$git push origin master 


版 本 库 super 是 准备 在 其 中 创建 子 模 组 的 。super 版 本 库 刚刚 初始 化 
还 未 包含 提交 ，master 分 支 尚 未 有 正确 的 引用 。 需 要 在 super 版 本 库 中 
至 少 创建 一 个 提交 。 下 面 就 死 隆 super 版 本 库 ， 在 其 中 完成 一 个 提交 

( 空 提交 即 可 ) ， 并 推送 。 


$git clone/path/to/repos/super.git/path/to/my/workspace/super 
$cd/path/to/my/workspace/super 

$git commit--allow-empty-m "initialized." 

$git push origin master 


现在 束 可 以 在 super 版 本 库 中 使 用 git submodule add 命 令 添加 子 模 
组 了 。 


$git submodule add/path/to/repos/libA.git lib/lib_a 
$git submodule add/path/to/repos/libB.git lib/lib_b 


至 此 看 一 下 super 版 本 库 工 作 区 的 目录 结构 。 在 根 目 了 永 下 多 了 一 
个 .gitmodules 文 件 ， 并 且 两 个 函数 库 分 别 被 克隆 到 liby/lib_a 目 永和 
lib/lib_b 目 隶 下 。 


$1s-aF 
./../.git/.gitmodules lib/ 


看 看 .gitmodules 的 内 容 : 


$cat .gitmodules 

[submodule "1ib/l1ib_a"] 
path=1ib/lib_a 
url=/path/to/repos/l1ibA.git 


[submodule "1ib/l1ib_b"] 
path=1ib/1ib_b 
url=/path/to/repos/l1ibB.git 


此 时 super 的 工作 区 尚未 提交 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe"git reset HEAD<file>..."to unstage) 
# 

#new file: .gitmodules 

#new file:lib/lib _a 

#new file:l1lib/lib_b 

# 


完成 提交 之 后 ， 子 模 组 才 算 正式 在 super 版 本 库 中 创立 。 运 行 git 
push 把 建立 了 新 模 组 的 本 地 版 本 库 推送 到 远程 版 本 库 。 


$git commit-m "add modules in lib/lib_a and lib/lib _b." 
$git push 


在 提交 过 程 中 ， 发 现 作 为 子 模 组 方式 添加 的 版 本 库 实际 上 并 没有 
添加 版 本 库 的 内 容 。 实 际 上 只 是 以 gitlink 的 方式 添加 了 一 个 链接 。 至 
于 子 模 组 的 实际 地 址 ， 是 由 文件 .gitmodules 指 定 的 。 


可 以 通过 查看 补丁 的 方式 看 到 lib/lib _a 和 libylib_b 子 模 组 的 存在 方 
式 〈 即 gitlink) 。 
$git Show HEAD 


commit 19bb54239dd7c11151e0dcb8b9389e146f055ba9 
Author:Jiang Xin<jiangxin@ossxp.com> 


Date:Fri Oct 29 10:16:59 2010+0800 

add modules in lib/lib a and Jib/lib_b， 
diff--git a/.gitmodules b/.gitmodules 
new file mode 100644 

index 0000000. .60c7d1f 

---/dev/null 

+++b/ .gitmodules 

QQ-0,0+1, 6@@ 

+[submodule "lib/lib _a"] 
+path=1ib/lib_a 
+Uurl=/path/to/repos/1ibA.git 
+[submodule "lib/lib_b"] 
+path=1ib/1ib_b 
+url=/path/to/repos/1ibB.git 

diff--git a/lib/lib a b/lib/lib _a 

new file mode 160000 

index 0000000. .126b181 

---/dev/null 

+++b/l1ib/l1ib_a 

@@-0,0+1@@ 

+Subproject commit 126b18153583d9bee4562f9af6b9706d2e104016 
diff--git a/lib/lib _b b/lib/lib_b 

new file mode 160000 

index 0000000. .3b52a71 

---/dev/null 

+++b/l1ib/lib_b 

QQ@-0, 0+106 

+Subproject commit 3b52a710068edc070e3a386a6efcbdf28bf1ibed5 


23.2 ”克隆 带子 檬 组 的 版 本 库 


之 前 的 表 23-1 在 对 比 Subversion 的 svn:externals 属 性 和 Git 子 模 组 实 
现 差异 时 ， 提 到 过 克隆 带子 模 组 的 Git 库 ， 并 不 能 自动 将 子 模 组 的 版 本 
库 元 隆 出 来 。 对 于 只 关心 项 目 本 身 的 数据 ， 而 不 关心 项 目 引 用 的 外 部 
项 目 数据 的 用 户 ， 这 个 功能 非常 好 ， 数 据 没 有 见 余 而 且 克 隆 的 速度 也 
更 快 。 


下 面 在 另外 的 位 置 克 隆 super 版 本 库 ， 会 发 现 libylib_a 和 1libylib_b 并 
未 克隆 。 


$git clone/path/to/repos/super.git/path/to/my/workspace/super- 
clone 

$cd/path/to/my/workspace/super-clone 

$1s-aF 

./../.git/.gitmodules 1ib/ 

$find 1ib 

1ib 

1ib/lib_a 

1ib/lib_b 


这 时 如 果 运 行 git submodule status 可 以 查看 到 子 模 组 的 状态 。 


$git submodule status 
-126b18153583d9bee4562f9af6b9706d2e104016 lib/lib a 
-3b52a710068edc070e3a386a6efcbdf28bf1ibed5 1ib/lib_b 


可 以 看 到 ， 每 个 子 模 组 的 目 孙 前 面 都 是 40 位 的 提交 ID ， 最 前 面 的 
是 一 个 城 豆 。 减 号 的 舍 义 是 该 子 模 组 尚未 检 出 。 


如 果 需 要 克隆 出 子 模 组 形式 引用 的 外 部 库 ， 首 先 需 要 执行 git 


submodule init ° 


$git submodule init 

Submodule 'lib/lib a' (/path/to/repos/l1ibA.git)registered for 
path ‘lib/lib _a' 

Submodule '1lib/lib _b' (/path/to/repos/1libB.git)registered for 
path ‘lib/lib_b' 


执行 git submodule init 实 际 上 修改 了 .git/config 文 件 ， 对 子 模 组 进行 
了 注册 。 文 件 .git/config 的 修改 示例 如 下 (以 加 号 开始 的 行 代表 新 增 的 


1) 


[core] 
repositoryformatversion=0 
filemode=true 

bare=false 
logallrefupdates=true 
[remote"origin"] 
fetch=+refs/heads/*:refs/remotes/origin/* 
url=/path/to/repos/super .git 
[branch "master"] 
remote=origin 
merge=refs/heads/master 
+[submodule "lib/lib _a"] 
+url=/path/to/repos/l1ibA.git 
+[submodule "lib/lib_b"] 
+url=/path/to/repos/1ibB.git 


然后 执行 git submodule update 完 成 子 模 组 版 本 库 的 克隆 。 


$git submodule update 

Initialized empty Git repository in 
/path/to/my/workspace/super-clone/lib/1lib a/.git/ 
Submodule path '1ib/1lib_a':checked out 
"126b18153583d9bee4562f9af6b9706d2e104016 
Initialized empty Git repository in 
/path/to/my/workspace/super-clone/lib/1lib _b/.git/ 
Submodule path '1ib/1lib_b':checked out 
"3b52a710068edc070e3a386a6efcbdf28bf1bed5， 


23.3 ”在 子 模 组 中 修改 和 子 模 组 的 更 新 


执行 git submodule update 更 狐 出 来 的 子 模 组 ， 都 以 某 个 具体 的 提 
交 版 本 进行 检 出 。 进 入 某 个 子 模 组 日 录 ， 会 发 现 其 处 于 非 跟踪 状态 
(分 离 头 指针 状态 ) 


$cd/path/to/my/workspace/super-clone/lib/1lib a 
$git branch 

*(no branch) 

master 


显然 这 种 情况 下 ， 如 果 修 改 lib/lib_a 下 的 文件 ， 提 交 束 会 丢失 。 下 
面 介绍 一 下 如 何在 检 出 的 子 模 组 中 修改 ， 以 及 如 何 更 新 子 模 组 。 


在 子 模 组 中 切换 到 master 分 文 《或 其 他 想 要 修改 的 分 文 ) 后 再 进 
行 修改 。 


(1) 切换 到 master 分 支 ， 然 后 在 工作 区 做 一 些 改动 。 


$cd/path/to/my/workspace/super-clone/lib/1lib a 
$git checkout master 
hack... 


$git commit 


(3) 查看 状态 ， 会 看 到 相对 于 远程 分 支 领先 一 个 提交 。 


$git status 

#0n branch master 

#Your branch is ahead of 'origin/master' by 1 commit. 
# 

nothing to commit(working directory clean) 


在 git status 的 状态 输出 中 ， 可 以 看 出 新 提交 尚未 推送 到 远程 版 本 
库 。 现 在 暂时 不 推送 ， 看 看 在 super 版 本 库 中 执行 git submodule update 
对 子 模 组 的 影响 ， 具 体操 作 过 程 如 下 。 


(4) 先 到 super-clone 版 本 库 查 看 一 下 状态 ， 可 以 看 到 子 模 组 已 修 
改 ， 包 含 了 更 新 的 提交 。 


$cd/path/to/my/workspace/super-clone/ 
$git status 

#0n branch master 

#Changed but not updated: 


#(USe "git add<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 

#modified:1ib/lib _ a(new commits) 

# 


no changes added to commit(use "git add" and/or "git commit-a") 


(5) 通过 git submodule stauts 命 令 可 以 看 出 lib/lib_a 子 模 组 指向 了 
新 的 提交 ID (前 面 有 一 个 加 号 ; ， 而 lib/ib_b 子 模 组 状态 正常 (提交 ID 


前 是 一 个 空格 ， 不 是 加 号 也 不 是 减 号 ) 。 


$git submodule status 


+5dea2693e5574a6e3b3a59c6boc68cb08b2c07e9 
1ib/lib_a(heads/master) 
3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/1lib_b(heads/master) 


(6) 这 时 如 果 不 小 心 执 行 了 一 次 git submodule update 命 令 ， 会 将 
lib/lib_a 重 新 切换 到 旧 的 指向 。 
$git submodule update 


Submodule path '1ib/1lib_a':checked out 
'126b18153583d9bee4562f9af6b9706d2e104016 


(7) 执行 git submodule status 命 令 查 看 子 模 组 状态 ， 可 以 看 到 
lib/lib_a 子 模 组 被 重 置 了 。 


$git submodule status 

126b18153583d9bee4562f9af6b9706d2e104016 
1ib/l1ib_a(remotes/origin/HEAD) 

3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/1lib_b(heads/master) 


那么 刚才 在 lib/lib_a 中 的 提交 丢失 了 么 ? 实际 上 因为 已 经 提交 到 了 
master 主 线 ， 因 此 提交 没有 丢失 ， 但 是 如 果 有 数据 没有 提交 ， 束 会 造 
成 未 提交 数据 的 丢失 。 


(1) 进 到 lib/lib_ a 目 录 ， 看 到 工作 区 再 一 次 进入 分 离 头 指针 状 


~ 
C 
- 


$cd 1ib/lib a 
$git branch 
*(no branch) 
master 


(2) 重新 检 出 master 分 支 找 回 之 前 的 提交 。 


$git checkout master 

Previous HEAD position was 126b181...add data for libA 
Switched to branch 'master' 

Your branch is ahead of 'origin/master' by 1 commit. 


现在 如 果 要 将 lib/lib_a 目 录 下 子 模 组 的 改动 记录 到 父 项 目 (super 版 
本 库 ) 中 ， 就 需要 在 父 项 目 中 进行 一 次 提交 才能 实现 。 


(1) 进入 父 项 目 根 目录 查看 状态 。 因 为 libylib_a 的 提交 已 经 恢 
复 ， 因 此 再 次 显示 为 有 改动 。 


$cd/path/to/my/workspace/super-clone/ 
$git status-s 
M 1ib/lib a 


(2) 查看 差异 比较 ， 会 看 到 指向 子 模 组 的 gitlink 有 改动 。 


$git diff 

diff--git a/lib/lib a b/lib/lib _a 

index 126b181..5dea269 160000 

---a/lib/lib_a 

+++b/l1ib/l1ib_a 

@@-1+1@@ 

-Subproject commit 126b18153583d9bee4562f9af6b9706d2e104016 
+Subproject commit 5dea2693e5574a6e3b3a59c6boc68cb08b2c07e9 


(3) 将 gitink 的 改动 添加 到 暂 存 区 ， 然 后 提交 。 


$git add-u 
$git commit-m "submodule lib/lib a upgrade to new version." 


此 时 先 不 要 忙 着 推送 ， 因 为 如 果 此 时 执行 git push 将 super 版 本 库 推 
送 到 远程 版 本 库 ， 会 引发 一 个 问题 。 即 推送 后 的 远程 super 版 本 库 的 子 
模 组 lib/lib_a 指 向 了 一 个 新 的 提交 ， 而 该 提交 还 在 本 地 的 lib/llib_a 版 本 
库 (尚未 向 上 游 推 送 ) ， 这 会 导致 其 他 人 克隆 super 版 本 库 和 更 新 模 组 
时 因为 找 不 到 该 子 模 组 版 本 库 相 应 的 提交 而 出 错 。 下 面 就 是 这 类 错误 
的 信息 : 


fatal:reference is not a 
tree:5dea2693e5574a6e3b3a59c6b0c68cb08b2c07e9 

Unable to checkout '5dea2693e5574a6e3b3a59c6boc68cb08b2c07e9' in 
submodule path 

'l1ib/lib a' 


为 了 避免 这 种 可 能 性 的 发 生 ， 最 好 先 推送 lib/lib_a 中 的 新 提交 ， 然 
后 再 癌 super 版 本 库 推送 更 狐 的 子 模 组 gitlink 改 动 。 即 : 


(1) 先 推送 子 模 组 。 


$cd/path/to/my/workspace/super-clone/lib/lib _a 
$git push 


(2) 再 推送 父 版 本 库 。 


$cd/path/to/my/workspace/super-clone/ 
$git push 


23.4” 隐 性 子 栋 组 


我 在 开发 备份 工具 Gistore 中 时 过 到 一 个 严 手 的 问题 ， 就 是 隐 性 子 
模 组 的 问题 。Gistore 备 份 工 具 的 原理 是 将 要 备份 的 目录 都 挂 载 
(mount) 在 工作 区 中 ， 然 后 执行 git add。 但 是 如 果 有 某 个 目录 已 经 被 
Git 化 了 ， 束 只 会 以 子 模 组 的 方式 将 该 目 孙 添加 进来 ， 而 不 会 添加 该 目 
杂 下 的 文件 。 对 于 一 个 备份 工具 来 说 ， 这 就 意味 着 备份 没有 成 功 。 具 
体操 作 过 程 如 下 : 


(1) 例如 当前 super 版 本 库 下 有 两 个 子 模 组 : 


$cd/path/to/my/workspace/super-clone/ 

$git submodule status 

126b18153583d9bee4562f9af6b9706d2e104016 
1ib/l1ib_a(remotes/origin/HEAD) 

3b52a710068edc070e3a386a6efcbdf28bf1bed5 1ib/1lib_b(heads/master) 


2) 然后 创建 一 个 新 目录 others， 并 把 该 目录 用 Git 初 始 化 ， 并 做 


( 
一 次 空 的 提交 。 


$mkdir others 

$cd others 

$git init 

$git commit--allow-empty-m initial 
[master(root-commit)90364e1]initial 


(3) 在 others 目 录 下 创建 一 个 文件 newfile 。 


$date>newfile 


(4) 回 到 上 一 级 目录 执行 git status， 看 到 有 一 个 others 目 录 没 有 加 
入 版 本 库 控制 ， 这 很 自然 。 


$cd, ， 

$git status 

#0n branch master 
#Untracked files: 


#(USe "git add<file>..." to include in what will be committed) 
# 
#0thers/ 


nothing added to commit but untracked files present(use "git 
add" to track) 


(5) 但 是 如 果 对 others 目 录 执 行 git add 后 ， 会 发 现 奇怪 的 状态 。 


$git add others 

$git status 

#0n branch master 
#Changes to be committed: 


#(USse "git reset HEAD<file>..." to unstage) 

# 

#new file:others 

# 

#Changed but not updated: 

#(USe "git add<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 


#(commit or discard the untracked or modified content in 
submodules) 

# 

#modified:others(untracked content) 

# 


(6) 看 看 others 目 录 的 添加 方式 ， 束 会 发 现 others 目 录 以 gitlink 的 
方式 添加 到 版 本 库 中 ， 而 没有 把 该 目录 下 的 文件 添加 到 版 本 麻 中 。 


$git diff--cached 

diff--git a/others b/others 

new file mode 160000 

index 0000000. .90364e1 

---/dev/null 

+++b/others 

@@-0,0+1@@ 

+Subproject commit 90364e1331abc29cc63e994b4d2cfbf7c485e4ad 


之 所 以 上 面 的 步骤 (5) 运行 git status 命 令 时 others 出 现 了 两 次 ， 就 
是 因为 目 了 永 others 被 当 作 子 模 组 添加 到 了 父 版 本 库 中 ， 而 且 由 于 others 


版 本 库 本 身 “ 不 干净 ”， 存 在 尚未 加 入 版 本 控制 的 文件 ， 所 以 又 在 状态 
输出 中 显示 了 子 模 组 包含 改动 的 提示 信息 。 


接 下 来 执行 提交 ， 将 others 目 录 提 区 到 版 本 库 中 。 然 后 当 执行 git 
submoudle status 命 令 时 会 报销 。 因 为 others 作 为 子 模 组 没有 
在 .gitmodules 文 件 中 注册 。 


$git commit-m "add others as submodule." 

$git submodule status 

126b18153583d9bee4562f9af6b9706d2e104016 
1ib/l1ib_a(remotes/origin/HEAD) 

3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/1lib_b(heads/master) 

No submodule mapping found in.gitmodules for path "others' 


那么 如 何在 不 破坏 others 版 本 库 的 前 提 下 ， 把 others 目 录 下 的 文件 
加 入 版 本 库 昵 ? 即 避 免 others 以 子 模 组 形式 添加 入 库 ， 有 具体 操作 过 程 如 


(1) 先 删 除 以 gitlink 形 式 入 库 的 others 子 模 组 。 


$git rm--cached others 
rm "others' 


(2) 查看 当前 状态 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..." to unstage) 
# 

#deleted:others 

# 

#Untracked files: 

#(USe "git add<file>..." to include in what will be committed) 
# 

#0thers/ 


(3) 重新 添加 others 目 隶 ， 注 意 目 录 后 面 的 斜 线 ( 即 路 径 分 隔 
符 ) 非常 重要 。 


$git add others/ 


(4) 再 次 查看 状态 ， 看 到 others 下 的 文件 被 添加 到 super 版 本 库 
中 o 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..." to unstage) 


# 

#deleted:others 

#new file:others/newfile 
# 


(5) 执行 提交 。 


$git commit-m "add contents in others/." 
[master 1egc418]add contents in others/， 

2 files changed,1 insertions(+),1 deletions(-) 
delete mode 160000 others 

create mode 100644 others/newfile 


在 上 面 的 操作 过 程 中 ， 首 先 删除 了 库 中 的 others 子 模 组 (使 用 -- 
cached 参 数 执行 删除 ;然后 为 了 添加 others 目 录 下 的 文件 使 用 
了 "others/" (注意 others 后 面 的 路 径 分 割 符 “/w) 。 现 在 查看 一 下 子 模 组 
的 状态 ， 会 看 到 只 显示 出 了 之 前 的 两 个 子 模 组 。 


$git submodule status 

126b18153583d9bee4562f9af6b9706d2e104016 
1ib/l1ib_a(remotes/origin/HEAD) 

3b52a710068edc070e3a386a6efcbdf28bfibed5 1ib/1lib_b(heads/master) 


[1] 参见 本 书 第 7 篇 “第 37 革 Gistore”。 


23.5“ 子 模 组 的 管理 问题 


子 模 组 最 主要 的 一 个 问题 是 不 能 基于 外 部 版 本 库 的 某 一 个 分 支 进 
行 创建 ， 而 使 得 更 新 后 子 模 组 处 于 非 跟 踩 状态， 不 便于 在 子 模 组 中 进 
行 代码 修改 、 提 交 和 向 外 部 推送 。 尤 其 对 于 因 授 权 或 其 他 原因 将 一 个 
版 本 库 拆 分 为 子 模 组 后 ， 使 用 和 管理 非常 不 方便 。 在 “第 25 章 
Android 式 多 版 本 库 协 同 ”一 章 中 可 以 看 到 管理 多 版 本 库 的 男 外 一 个 可 


行 方案 。 


如 琳 在 局 域 网 内 维护 的 版 本 库 所 引用 的 子 模 组 版 本 库存 在 于 男 外 
的 服务 右上， 甚至 互联 网 上 ， 克 隆子 版 本 库 束 要 浪费 很 多 时 间 。 而 且 
如 有 果子 模 组 指 同 的 版 本 库 不 在 我 们 的 掌控 之 内 ， 一 旦 需要 对 其 进行 定 
制 ， 束 会 因为 无 法 癌 远 程 服 务 右 推送 提交 而 无 法 实现 定制 。 下 一 划 
即 “ 第 24 章 “ 子 树 合并 ?会 给 出 针对 这 个 问题 的 解决 方案 。 


第 24 章 ” 子 树 合并 


使 用 子 树 合 并 ， 同 样 可 以 实现 在 一 个 项 目 中 引用 其 他 项 目的 数 
据 。 但 是 和 子 模 组 方式 不 同 的 是 ， 使 用 子 树 合 并 模式 ， 外 部 的 版 本 库 
会 作为 一 个 目录 被 整个 复制 到 本 版 本 库 中 ， 并 且 复 制 到 本 版 本 库 中 的 
于 目录 下 的 数据 可 以 和 原版 本 库 数 据 建立 跟踪 关联。 使 用 子 树 合并 飘 
式 ， 对 源 目 外 部 版 本 库 的 数据 的 访问 和 对 本 版 本 库 数 据 的 访问 没有 区 
别 ， 也 可 以 对 其 进行 本 地 修改 ， 并 且 能 够 以 子 树 合并 的 方式 将 外 部 版 
本 库 的 新 的 改动 和 本 地 的 修改 相合 并 。 


24.1 引入 外 部 版 本 库 


为 演示 子 树 合并 至 少 需 要 准备 两 个 版 本 库 ， 一 个 十 将 要 被 作为 于 
目 邓 引入 的 版 本 库 util.git， 男 外 一 个 是 主 版 本 库 main.git 。 


$git--git-dir=/path/to/repos/util.git init--bare 
$git--git-dir=/path/to/repos/main.git init--bare 


在 本 地 检 出 这 两 个 版 本 库 : 


$cd/path/to/my/workspace 
$git clone/path/to/repos/util.git 
$git clone/path/to/repos/main.git 


需要 为 这 两 个 空 版 本 库 添加 些 数据 。 非 常 简单 ， 每 个 版 本 库 下 只 
创建 两 个 文件 ， Makefile 和 version。 当 执行 make 命 令 时 显示 version 文 
件 的 内 容 。 对 version 文 件 多 次 提交 以 建立 多 个 提交 历史 。 别 起 了 在 最 
后 使 用 git push origin master 将 版 本 库 推 送 到 远程 版 本 库 中 。 


Makefile 文 件 示例 如 下 。 注 意 第 二 行 前 面 的 至 日 是 <TAB > 字符 ， 
而 非 空 格 。 


all: 
Q@cat version 


在 之 前 笑 试 的 git fetch 命 令 都 是 获取 同一 项 目的 版 本 库 的 内 容 。 其 
实 命令 git fetch 从 哪个 项 目 获取 数据 并 没有 什么 限制 ， 因 为 Git 的 版 本 
库 不 像 Subversion 那 样 用 一 个 唯一 的 UUID 标 识 让 Subversion 的 版 本 库 之 
间 势 同 水 火 。 当 然 也 可 以 用 git pull 来 获取 其 他 版 本 库 中 的 提交 ， 但 是 
那样 将 把 两 个 项 目的 文件 彻底 混杂 在 一 起 。 对 于 这 个 示例 来 说 ， 因 为 
两 个 项 目 具 有 同样 的 文件 Makefile 和 version， 使 用 git pull 将 导致 冲突 。 
所 以 为 了 将 不 同 项 目的 版 本 库 引 入 ， 并 在 稍 后 以 子 树 合并 的 方式 添加 
到 一 个 子 目 录 中 ， 需 要 用 git fetch 命 令 从 其 他 版 本 库 获取 数据 ， 具 体操 
作 过 程 如 下 。 


(1) 为 了 便于 以 后 对 外 部 版 本 库 的 跟踪， 在 使 用 git fetch 前 ， 先 
在 main 版 本 库 中 注册 远程 版 本 库 util.git 。 


$cd/path/to/my/workspace/main 
$git remote add util/path/to/repos/util.git 


(2) 查看 注册 的 远程 版 本 库 。 


$git remote-v 
origin/path/to/repos/main.git/(fetch) 
origin/path/to/repos/main.git/(push) 
util/path/to/repos/util.git(fetch) 
util/path/to/repos/util.git(push) 


(3) 执行 git fetch 命 令 获 取 util.git 版 本 库 的 提交 。 


$git fetch util 


(4) 查看 分 文 ， 包 括 远 程 分 支 。 


$git branch-a 

*master 
remotes/origin/master 
remotes/util/master 


在 不 同 的 分 文 : master 分 支 和 remotes/util/master 分 支 中 ， 文 件 
version 的 内 容 并 不 相同 ， 因 为 来 目 不 同 的 上 游 版 本 库 。 


在 master 分 文中 执行 make 命 令 ， 显 示 的 是 main.git 版 本 库 中 version 
文件 的 内 容 。 


$make 
main v2010.1 


从 utiymaster 远 程 分 文 创建 一 个 本 地 分 文 util-branch， 并 切换 分 
支 o 
$git checkout-b util-branch util/master 
Branch util-branch set up to track remote branch master from 


util. 
Switched to a new branch 'util-branch' 


执行 make 命 令 ， 显 示 的 是 util.git 版 本 库 中 version 文 件 的 内 容 。 


$make 
util v3.0 


像 这 样 在 main.git 中 引入 util.git 显 然 不 能 满足 需要 ， 因 为 在 main.git 
的 本 地 克隆 版 本 库 中 ，master 分 文 访 问 不 到 只 有 在 util-branch 分 文中 才 
出 现 的 util 版 本 库 数 据 。 这 融 需 要 做 进一步 的 工作 ， 将 两 个 版 本 库 的 内 
容 合 并 到 一 个 分 支 中 。 即 将 util-branch 分 支 的 数据 作为 子 目 录 加 入 到 


master 分 支 中 


24.2 了 于 目录 方式 合并 外 部 版 本 库 


下 面 就 用 Git 的 接 层 命令 git read-tree 、git write-tree 和 git commit-tree 
子 命令 ， 实 现 将 util-branch 分 文 所 包含 的 util.git 版 本 库 的 目录 树 以 子 目 
录 (lib/) 的 形式 添加 到 master 分 文中 。 


完 来 看 看 util-branch 分 文 当前 的 最 新 提交 ， 记 住 最 新 提交 所 指向 的 
目录 树 (tree) ， 即 tree id: 0c743e4。 
$git cat-file-p util-branch 
tree 0c743e49e11019678c8b345e667504cb789431ae 
parent f21f9c10cc248a4a28bf7790414baba483f1ec15 
author Jiang Xin<JjiangxinQ@ossxp.com>1288494998+0800 


committer Jiang Xin<jiangxin@ossxp.com>1288494998+0800 
Util v2.0->v3.0 


查看 tree 0c743e4 所 包含 的 内 容 ， 会 看 到 两 个 文件 Makefile 和 


version ° 


$git cat-file-p Qc743e4 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
100644 blob bebe6b10eb9622597dd2b641efe8365c3638004e version 


切换 到 master 分 支 ， 以 如 下 方式 调用 git read-tree 将 util-branch 分 文 
的 目录 树 读 取 到 当前 分 支 lib 目 录 下 ， 具 体操 作 过 程 如 下 。 


(1) 切换 到 master 分 支 。 


$git checkout master 


(2) 执行 git read-tree 命 令 ， 将 分 支 util-branch 读 取 到 当前 分 支 的 
二 人 相当 


$git read-tree--prefix=1lib util-branch 


(3) 调用 git read-tree 只 是 更 新 了 和 暂 存 区 ， 所 以 查看 工作 区 状态 会 
看 到 工作 区 中 还 不 存在 lib 目 录 下 的 两 个 文件 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(UusSe "git reset HEAD<file>..." to unstage) 
# 

#new file:lib/Makefile 

#new file:1ib/version 


# 

#Changed but not updated: 

#(USe "git add/rm<file>..." to update what will be committed) 

#(USe "git checkout--<file>..." to discard changes in working 
directory) 

# 


#deleted:l1lib/Makefile 
#deleted:1ib/version 
# 


(4) 执行 检 出 命令 ， 将 ]ib 目 录 下 的 文件 更 新 出 来 。 


$git checkout--1ib 


(5) 再 次 查看 状态 ， 会 看 到 前 面 执行 的 git read-tree 命 令 添加 到 了 
暂 存 区 的 文件 中 。 


$git status 

#0n branch master 

#Changes to be committed: 

#(USe "git reset HEAD<file>..." to unstage) 
基 

#new file:lib/Makefile 

#new file:1ib/version 

式 


现在 还 不 能 忙 着 提交 ， 因 为 如 果 现 在 进行 提交 就 体现 不 出 两 个 分 
文 的 合并 关系 。 需 要 使 用 Git 底 层 的 命令 进行 数据 提交 ， 具 体操 作 过 程 
Ry 


(1) 调用 git write-tree 将 暂 存 区 的 目录 树 保 存 下 来 。 
要 记 住 调用 git write-tree 后 形成 的 新 的 tree-id: 2153518。 


$git write-tree 
2153518409d218609af40babededec6e8ef51616 
(2) 执行 git cat-file 命 令 显示 这 棵 树 的 内 容 ， 会 注意 到 其 中 ]ib 目 
孙 的 tree-id 和 之 前 查看 过 的 util-branch 分 支 最 新 的 提交 对 应 的 tree-id 一 
样 都 是 0c743e4 。 


$git cat-file-p 2153518409d218609af40babededec6e8ef51616 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
040000 tree Qc743e49e11019678c8b345e667504cb789431ae 1ib 
100644 blob 638c7b7c6bdbde1d29e0b55b165f755c8c4332b5 


version 


(3) 要 手工 创建 一 个 合并 提交 ， 即 新 的 提交 要 有 两 个 父 提交 。 这 
两 个 父 提交 分 别 是 master 分 支 和 util-branch 分 支 的 最 新 提交 。 用 下 面 的 
命令 显示 两 个 提交 的 提交 ID， 并 记 下 这 两 个 提交 ID。 


$git rev-parse HEAD 
911b1af2e0c95a2fc1306b8dea707064d45386c2e 
$git rev-parse util-branch 
12408a149bfa78a4c2d4011f884aa2adb04f0934 


(4) 执行 git commit-tree 命 令 手动 创建 提交 。 新 提交 的 目录 树 来 
自 上 面 的 git write-tree 产 生 的 目录 树 (tree-id 为 2153518) ， 而 新 提交 
(合并 提交 ) 的 两 个 父 提交 直接 用 上 面 git rev-parse 显 示 的 两 个 提交 I 
表示 。 


$echo "subtree merge"|\ 

git commit-tree 2153518409d218609af40babededec6e8ef51616\ 
-p 911ibiaf2e0c95a2fc1306b8dea707064d5386c2e\ 

-p 12408a149bfa78a4c2d4011f884aa2adb04f0934 
62ae6cc3f9280418bdbofcf6c1e678905b1fe690 


(5) 执行 git commit-tree 命 令 的 输出 是 提交 之 后 产生 的 新 提交 的 
提交 ID。 和 需要 把 当前 的 master 分 文 重 置 到 此 提交 ID 。 


$git reset 62ae6cc3f9280418bdbofcf6c1e678905b1fe690 


(6) 查看 一 下 提交 日 志 及 分 文 图 ， 可 以 看 到 通过 复杂 的 git read- 
tree、git write-tree 和 git commit-tree 命 令 制造 的 合并 提交 ， 的 确 将 两 个 


不 同 的 版 本 库 合并 到 一 起 了 。 


$git log--graph--pretty=oneline 
*62ae6cc3f9280418bdbofcf6c1e678905b1fe690 subtree merge 

人 

|*12408a149bfa78a4c2d4011f884aa2adb04f0934 Util v2.0->v3.0 
|*f21f9c10cc248a4a28bf7790414baba483f1lec15 util v1.0->v2.0 
1*76dboad729db9fdc5be043f3b4ed94ddc945cd7f util v1.0 
*911b1af2e0c95a2fc1306b8dea707064d5386c2e main v2010.1 


(7) 看 看 现在 的 master 分 支 。 


$git cat-file-p HEAD 

tree 2153518409d218609af40babededec6e8ef51616 

parent 911b1af2e0c95a2fc1306b8dea707064d5386c2e 

parent 12408a149bfa78a4c2d4011f884aa2adb04f0934 

author Jiang Xin<jiangxin@ossxp.com>1288498186+0800 
committer Jiang Xin<jiangxin@ossxp.com>1288498186+0800 
subtree merge 


(8) 看 看 日 录 树 。 


$git cat-file-p 2153518409d218609af40babededec6e8ef51616 
100644 blob 07263ff95b4c94275f4b4735e26ea63b57b3c9e3 Makefile 
040000 tree 0c743e49e11019678c8b345e667504cb789431ae 1ib 
100644 blob 638c7b7c6bdbde1d29e0b55b165f755c8c4332b5 version 


整个 过 程 非常 紧 开 ， 但 十 不 要 太 过 担心 ， 只 需要 对 原理 了 解 清楚 
就 可 以 了 ， 因 为 在 后 面 会 介绍 一 个 Git 插 件 ， 它 封装 了 复杂 的 子 树 合并 
操作 。 


24.3 ”利用 子 网 合并 跟踪 上 游 改动 


如 果子 树 (1ib 目录 ) 的 上 游 ( 即 util.git) 包含 了 新 的 提交 ， 如 何 将 util.git 
的 新 提交 合并 过 来 呢 ? 这 就 要 用 到 名 为 subtree 的 合并 策略 中 。 


在 执行 子 树 合 并 之 前 ， 先 切换 到 util-branch 分 文 ， 获 取 远 程 版 本 库 
的 改动 。 


$git checkout util-branch 

$git pull 

remote:Counting objects:8,done. 
remote:Compressing objects:100%(4/4),done. 
remote:Total 6(delta 0),reused 0(delta 0) 
Unpacking objects:100%(6/6),done. 
From/path/to/repos/util 

12408al1. .5aba14f master->util/master 
Updating 12408a1. .5aba14f 

Fast-forward 

version|2+- 

1 files changed,1 insertions(+),1 deletions(-) 
$git checkout master 


在 切换 回 master 分 文 后 ， 如 果 这 时 执行 git merge util-branch， 会 将 
uitl-branch 的 数据 直接 合并 到 master 分 文 的 根 目 隶 下， 而 实际 上 是 希望 
合并 发 生 在 lib 目 孙 中 ， 这 残 需要 以 如 下 方式 进行 调用 ， 以 subtree 策 略 
进行 合并 。 


如 果 Git 的 版 本 小 于 1.7， 直 接 使 用 subtree 合 并 策略 。 


$git merge-s subtree util-branch 


如 果 Git 的 版 本 是 1.7 之 后 ( 含 1.7) 的 版 本 ， 则 可 以 使 用 默认 的 
recursive 合 并 策略 ， 通 过 参数 -Xsubtree= < prefix>> 在 合并 时 使 用 正确 
的 子 树 进行 匹配 合并 。 避 免 了 使 用 subtree 合 并 策略 时 的 猜测 。 


$git merge-Xsubtree=1ib util-branch 


再 来 看 看 执行 子 树 合并 之 后 的 分 文 图 示 。 


$git log--graph--pretty=oneline 

*f1a33e55eea04930a500c18a24a8bd009ecd9ac2 Merge branch "util- 
branch 

|\ 

|*5aba14fd347fc22cd8fbd086c9f26a53276f15c9 util v3.1->v3.2 

|*a6d53dfcf78e8a874e9132def5ef87a2b2febfa5 util v3.0->v3.1 

*|62ae6cc3f9280418bdbofcf6c1e678905b1fe690 subtree merge 

| 
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|*12408a149bfa78a4c2d4011f884aa2adb04f0934 util v2.0->v3.0 

|*f21f9c10cc248a4a28bf7790414baba483f1lec15 util v1.0->v2.0 

1*76dboad729db9fdc5be043f3b4ed94ddc945cd7f util] v1.0 

*911b1af2e0c95a2fc1306b8dea707064d5386c2e main v2010.1 


[1] 参见 第 3 篇 第 16 章 “16.6 合 并 策略 ”。 


24.4 ”了 于 树 拆 分 


既然 可 以 将 一 个 代码 库 通过 子 树 合并 的 方式 作为 子 目录 加 入 到 男 
外 一 个 版 本 库 中 ， 反 之 也 可 以 将 一 个 代码 库 的 子 目录 独立 出 来 转换 为 
男 外 的 版 本 库 。 不 过 这 个 反 疝 过 程 非常 复 洒 。 要 将 一 个 版 本 库 的 子 目 
录 作 为 顶级 目录 导出 到 男 外 的 项 目 ， 洪 藏 的 条 件 是 要 导出 历史 ， 因 为 
如 有 果 不 关 心 历史 ， 直 接 找 贝 文件 重建 项 目 束 可 以 了 。 了 于 树 拆 分 的 大 致 
过 程 是 : 


(1) 找到 要 导出 的 目录 的 提交 历史 ， 并 反 向 排序 。 
(2) 依次 对 每 个 提交 执行 下 面 的 操作 。 
(3) 找 出 提交 中 导出 目录 对 应 的 tree id 。 


(4) 对 该 tree id 执行 git commit-tree 。 


(5) 执行 git commit-tree 要 保持 提交 信息 还 要 重新 设置 提交 的 


parents ° 
手工 执行 这 个 操作 复杂 且 易 出 错 ， 可 以 用 下 市 介绍 的 git-subtree 插 


件 ， 或 使 用 第 6 篇 第 35 章 的 “35.4 Git 版 本 库 整 理 ” 一 节 中 介绍 的 git filter- 
branch 子 目录 过 滤器 的 技术 。 


24.5 _git-subtree 插 件 


git-subtree 揪 件 机 用 shell 脚 本 开发 ， 安 装 之 后 为 Git 提 供 了 新 的 git 
subtree 命 令 ， 支 持 前 面 介绍 的 子 树 合并 和 子 树 拆 分 。 命 令 非常 简单 易 
用 ， 将 其 他 版 本 库 以 子 树 形 式 导 入 ， 再 也 不 必 和 底 层 的 Git 命 令 打交道 
国信 o 


安装 Git subtree 很 简单 ， 操 作 如 下 : 


$git clone git://github.com/apenwarr/git-subtree.git 
$cd git-subtree 

$make doc 

$make test 

$sudo make install 


下 面 就 来 介绍 Git subtree 的 常用 命令 。 
1.git subtree add 


命令 git subtree add 相 当 于 将 其 他 版 本 库 以 子 树 方式 加 入 到 当前 版 
本 库 。 用 法 如 下 : 


git subtree add[--squash]-P<prefix> <commit> 
git subtree add[--squash]-P<prefix><repository><refspec> 


其 中 可 选 的 --squash 的 含义 是 压缩 为 一 个 版 本 后 再 添加 。 


对 于 文中 的 示例 ， 为 了 将 util.git 合 并 到 main.git 的 lib 目 录 ， 可 以 直 
接 这 样 调用 : 


$git Subtree add-P lib/path/to/repos/util.git master 


不 过 推荐 的 方法 还 是 先 在 本 地 建立 util.git 版 本 库 的 退 踪 分 文 。 


$git remote add util/path/to/repos/util.git 
$git fetch util 

$git branch util-branch util/master 

$git subtree add-P 1ib util-branch 


2.git Subtree merge 


命令 git subtree merge 相 当 于 将 子 树 对 应 的 远程 分 文 的 更 新 重新 合 
并 到 子 树 中 ， 相 当 于 完成 了 git merge-s subtree 探 作 ， 用 法 如 下 : 


git Subtree merge[--squash]-P<prefix> <commit> 
其 中 可 选 的 --squash 的 含义 是 压缩 为 一 个 版 本 后 再 合并 。 


对 于 文章 中 的 示例 ， 为 了 将 util-branch 分 支 包含 的 上 游 的 最 新 改动 
合并 到 master 分 支 的 lib 目 录 中 ， 可 以 直接 这 样 调用 : 


$git subtree merge-P lib util-branch 


3.git subtree pull 


命令 git subtree pull 相 当 于 先 对 子 树 对 应 的 远程 版 本 库 执行 一 次 git 
fetch 控 作 ， 然 后 再 执行 git subtree merge。 用 法 如 下 : 


git subtree pull[--squash]-P<prefix><repository><refspec...> 


对 于 文章 中 的 示例 ， 为 了 将 util.git 版 本 库 的 master 分 支 包 含 的 最 新 
改动 合并 到 master 分 文 的 lib 上 日 录 中 。 可 以 直接 这 样 调 用 : 


$git subtree pull-P lib/path/to/repos/util.git master 


更 喜欢 用 前 面 介 绍 的 git subtree merge 命 令 ， 因 为 git subtree pull 存 
在 版 本 库 地 址 写 错 的 风险 。 


4.git subtree split 


命令 git subtree split 相 当 于 将 目 孙 拆 分 为 独立 的 分 文 ， 即 子 树 拆 
分 。 拆 分 后 形成 的 分 文 可 以 推送 到 一 个 新 的 版 本 库 中 ， 进 而 实现 用 原 
版 本 库 的 一 个 子 目 录 为 根 目录 创建 出 新 的 版 本 库 。 用 法 如 下 : 


git subtree split-P<prefix>[--branch<branch>][--onto...][-- 
ignore-joins] 
[--rejoin] <commit...> 


说 明 : 


该 命令 总 是 输出 子 树 拆 分 后 的 最 后 一 个 commit-id。 这 样 可 以 通过 
AN 
- 口 


管道 方式 传递 给 


其 他 命令 ， 如 git subtree push 命 令 。 


参数 --branch 提 供 拆 分 后 创建 的 分 文 名 称 。 如 果 不 提供 ， 只 能 通过 


git subtree split 命 令 提供 的 提交 ID 得 到 拆 分 的 结果 。 


参数 --onto 参 数 将 目录 拆 分 附加 于 已 经 存在 的 提交 上 。 
参数 --ignore-joins 忽 略 对 之 前 拆 分 历史 的 检查 。 


参数 --rejoin 会 将 拆 分 结 采 合并 到 当前 分 文 ， 因 为 采用 ours 的 合并 
策略 ， 不 会 破坏 当前 分 文 。 


5.git Subtree push 


命令 git subtree push 先 执行 子 树 拆 分 ， 再 将 拆 分 的 分 文 推送 到 远程 
服务 器 。 用 法 如 下 : 


git subtree push-P<prefix><repository><refspec...> 
该 命令 的 用 法 和 git subtree split 的 类 似 ， 这 里 就 不 再 袭 述 。 


[1| http://github.com/apenwarr/git-subtree/ 


第 25 章 ”Android 式 多 版 本 库 协 同 


Android 是 谷歌 (Google) 开发 的 适合 手持 设备 的 操作 系统 ， 提 供 
了 当前 最 吸引 眼球 的 开源 的 手持 设备 操作 平台 ， 大 有 超越 苹 采 
(Apple.com) 专 有 的 iOS 系 统 的 趋势 。 而 Android 的 源 代码 就 是 使 用 
Git 进 行 维护 的 。Android 项 目 在 使 用 Git 进 行 源 代码 管理 上 有 两 个 伟大 
的 创造 ， 一 个 是 用 Java 开 发 的 名 为 Gerrit 的 代码 审核 服务 器 (将 在 第 5 


篇 第 32 章 专题 介绍 ) ， 画 外 一 个 吏 是 本 章 要 重点 介绍 的 repo。 


repo 是 一 个 用 Python 语言 开发 的 命令 行 工 具 ， 可 以 更 方便 地 进行 
多 版 本 库 的 管理 。 先 来 看 看 Android 到 底 包 含 了 多 少 个 Git 库 : 


Android 的 版 本 库 管 理工 具 repo 


git://android.git,.kernel.org/tools/repo.git 


保存 GPS 配置 文件 的 版 本 库 。 


git://android.git.kernel.org/device/common.git 


160 多 个 其 他 的 版 本 库 (截至 2010 年 10 月 ) 。 


如 果 把 160 多 个 版 本 库 都 列 在 这 里 ， 泡 怕 各 位 的 下 巴 都 会 控 下 来 。 
那么 为 什么 Android 的 版 本 库 会 有 这 么 多 呢 ? 怎么 管理 这 么 复杂 的 版 本 


库 呢 ? 


Android 版 本 库 众 多 的 原因 ， 主 要 是 版 本 库 太 大 ， 以 及 Git 不 能 部 
分 检 出 。Android 的 版 本 库 有 接近 2 个 GB 之 大 。 如 采 把 所 有 的 东西 都 放 
在 一 个 库 中 ， 而 菜 个 开发 团队 感 兴趣 的 可 能 束 是 某 个 红 动 ， 或 者 旦 有 某 
个 应 用 ， 却 要 下 载 如 此 庞大 的 版 本 库 ， 是 有 些 说 不 过 去 。 


好 了 ， 既 然 接 受 了 Android 有 多 达 160 多 个 版 本 库 这 一 事实 ， 那 么 
Android 是 不 是 用 之 前 介绍 的 “ 子 模 组 ”方式 组 织 起 来 的 呢 ? 如 采 真 的 
用 “ 子 模 组 ”方式 来 管理 这 160 多 个 代码 库 ， 可 能 束 需 要 如 此 管理 : 


建立 一 个 索引 版 本 库 ， 在 该 版 本 库 中 ， 通 过 子 模 组 方式 ， 将 目 永 
一 个 一 个 地 对 应 到 这 160 多 个 版 本 库 。 


对 此 索引 版 本 库 执行 克隆 操作 后 ， 表 执行 git submodule init 命 令 。 


当 执 行 git submodule update 命 令 时 ， 开 始 分 别克 隆 这 160 多 个 版 本 
库 。 


如 采 想 修改 某 个 版 本 库 中 的 内 容 ， 需 要 进入 到 相应 的 子 模 组 目 
孙 ， 执 行 切 换 分 文 的 操作 。 因 为 子 模 组 是 以 某 个 固定 提交 的 状态 存在 
的 ， 是 不 能 更 改 的， 必须 先 切换 到 某 个 工作 分 文 后 ， 才 能 进行 修改 和 


提交 。 


如 果 要 将 所 有 的 子 模 组 都 切换 到 某 个 分 文 (如 master) 进行 修 
改 ， 必 须 目 己 通过 脚本 对 这 160 多 个 版 本 库 一 一 进行 切换 。 


Android 有 多 个 版 本 : android-1.0、android-1.5、..………. 、 android- 
2.2_r1.3..… 如 何 维护 这 么 多 的 版 本 呢 ? 也 许 索引 库 要 通过 分 文 和 里 程 
碑 ， 与 子 模 组 的 各 个 不 同 的 提交 状态 进行 对 应 。 但 是 由 于 子 模 组 的 状 
态 只 是 一 个 提交 ID， 如 何 能 够 动态 地 指定 到 分 文 ， 真 的 给 不 出 答案 。 


幸好 上 面 只 是 假设 。 聪 明 的 Android 程 序 设计 师 一 早 就 考虑 到 了 
Git 子 模 组 的 局 限 性 ， 以 及 多 版 本 库 管理 的 问题 ， 开 发 出 了 repo 这 一 工 
具 。 


一 、 


关于 repo 有 这 么 一 则 小 故事 : Android 之 父 安 迪 : 鲁 宾 在 回应 乔布斯 
关于 Android 太 开放 导致 开发 维护 更 麻烦 的 言论 时 ， 在 Twitter 上 留 了 
下 面 这 段 简 短 的 话 : 


the definition of open:"mkdir android; cd android; repo init-u 
git://android.git.kernel.org/platform/manifest.git; repo Sync; 
make" 


是 的 ， 就 是 repo 让 Android 的 开发 变 得 如 此 人 简单 。 


25.1 ”天 于 repo 


repo 是 Google 开 发 的 用 于 管理 Android 版 本 库 的 一 个 工具 。repo 并 
不 是 用 于 取代 Git， 而 是 用 Python 对 Git 进 行 了 一 定 的 封闭， 简化 了 对 多 
个 Git 版 本 库 的 管理 。 对 于 repo 管 理 的 任何 一 个 版 本 库 ， 都 需要 使 用 Git 


命令 进行 操作 。 
repo 的 使 用 过 程 大 致 如 下 : 


(1) 运行 repo init 命 令 ， 克 隆 Android 的 一 个 清单 库 。 这 个 清单 库 
和 前 面 假设 的 “ 子 模 组 方式 工作 的 索引 库 不 同 ， 是 通过 XML 技术 建立 
的 版 本 库 清 单 。 


(2) 清单 库 中 的 manifest.xml 文 件 ， 列 出 了 160 多 个 版 本 库 的 克隆 
方式 。 包 括 版 本 库 的 地 址 和 工作 区 地 址 的 对 应 关系 ， 以 及 分 文 的 对 应 
关系 。 

(3) 运行 repo sync 命 令 ， 开 始 同步 ， 即 分 别克 隆 这 160 多 个 版 本 
库 到 本 地 的 工作 区 中 。 


(4) 同时 对 160 多 个 版 本 库 执行 切换 分 支 操作 ， 切 换 到 某 个 分 
2 


[1] http://twitter.com/Arubin 


25.2 ” 安 狼 repo 


首先 下 载 repo 的 引导 脚本 ， 可 以 使 用 wget、curl 甚 至 浏览 右 从 
http://android.git.kernel.org/repo 上 下 载 。 把 repo 脚 本 设置 为 可 执行 ， 并 
复制 到 可 执行 的 路 径 中 。 在 Linux 上 可 以 用 下 面 的 指令 将 repo 下 载 并 复 
制 到 用 户主 目录 的 bin 目 录 下 。 


$curl-L-k http://android.git.kernel.org/repo>~/bin/repo 
$chmod a+x~/bin/repo 


为 什么 说 下 载 的 repo 只 是 一 个 引导 脚本 (bootstrap) 而 不 是 直接 称 
为 repo 昵 ? 因为 repo 的 大 部 分 功能 代码 不 在 其 中 ， 下 载 的 只 是 一 个 帮 
助 完成 整个 repo 程 序 继续 下 载 和 加 载 的 工具 。 如 有 果 您 是 一 个 程序 员 ， 
对 repo 的 执行 比较 好 奇 ， 可 以 一 起 来 分 析 一 下 repo 引 导 脚 本 。 人 否则 可 
以 直接 跳 到 下 一 条 。 


看 看 repo 引 导 脚 本 的 前 几 行 (为 方便 描述 ， 把 注释 和 版 权 信 息 过 
滤 掉 了 ) ， 会 发 现 一 个 神奇 的 魔法 : 


1 #!/bin/sh 

2 

3 REPO_URL='git://android.git,.kernel.org/tools/repo.git' 
4 REPO_REV=' stable' 


nm "exec" python-E "和 $9" "$@" wa "#$magic" 


5 
6 magic='--calling-python-from-/bin/sh--'" 
7 
8 if__name =='__main 


9 import sys 

10 if sys.argv[-1]=='#%s'%magic: 
11 del sys.argv[-1] 

12 del magic 


repo 引 有 导 脚 本 是 用 什么 语言 开发 的 ? 这 是 一 个 问题 。 


第 1 行 ， 有 经 验 的 Linux 开 发 者 会 知道 此 脚本 是 用 Shell 脚 本 语言 
发 的 。 


第 7 行 ， 是 这 个 魔法 的 最 神奇 之 处 。 既 是 一 条 合法 的 shell 语 句 ， 又 


是 一 条 合法 的 python 语 句 。 


第 7 行 如 果 作 为 shell 语 句 ， 执 行 exec， 用 python 调 用 本 脚本 ， 并 赫 
换 本 进程 。 三 引号 在 这 里 相当 于 一 个 空 字 串 和 一 个 单独 的 引号 。 


第 7 行 如 果 作 为 python 语 句 ， 三 引号 定义 的 是 一 个 字符 串 ， 字 符 串 
后 面 是 一 个 注释 。 实 际 上 第 1 行 到 第 7 行 ， 既 是 合法 的 shell 语 句 义 是 合 
法 的 python 语 句 。 从 第 8 行 开始 后 面 都 是 python 肢 本 了 。 


repo3| 导 脚本 无 论 是 用 shell 执 行 ， 还 是 用 python 执 行 ， 效 果 都 相当 
于 使 用 python 执 行 此 脚本 。 


repo 脚 本 的 真正 位 置 在 哪里 ? 可 以 通过 分 析 引 导 脚 本 repo 得 到 。 
在 引导 脚本 repo 的 main 函 数 中 ， 首 先 调用 _FindRepo 函 数 ， 从 当前 目录 
开始 依次 同上 递归 查找 .repomrepo/main.py 文 件 。 


in 
函数 _FindRepo 返 回 找到 的 .repomrepo/main.py 脚 本 文件 ， 以 及 包含 
repommain.py 的 .repo 目 未 。 如 采 找 到 了 .repomrepomain.py 脚 本 ， 则 把 程 
序 的 控制 权 交 给 .repo/repo/main.py 脚 本 (省 略 了 在 repo 开 发 库 中 执行 情 
况 的 判断 ) 


在 下 载 repo 引 导 脚 本 后 ， 没 有 初始 化 之 前 ， 当 然 不 会 存 
在 .repo/repo/main.py 脚 本 ， 这 时 必须 进行 初始 化 操作 。 


25.3 ”repo 和 清单 库 的 初始 化 


下 载 并 保存 repo3| 导 脚本 后 ， 建 立 一 个 工作 目录 ， 这 个 工作 目录 
将 作为 Android 的 工作 区 目录 。 在 工作 目录 中 执行 repo init-u <url>， 
完成 repo 完 整 的 下 载 及 项 目 清单 版 本 库 (manifest.git) 的 下 载 。 


$mkdir working-directory-name 
$cd working-directory-name 
$repo init-u git://android.git.kernel.org/platform/manifest.git 


命令 repo init 要 完成 如 下 操作 : 


完成 repo 这 一 工具 的 完整 下 载 ， 因 为 现在 有 的 不 过 是 repo 的 引导 
程序 。 


初始 化 操作 会 从 android 的 代码 中 克隆 repo.git 库 到 当前 目录 下 
的 .repo/repo 目 录 下 。 在 完成 repo.git 克 隆之 后 ，repo init 命 令 会 将 控制 权 
交 给 工作 区 的 .repo/repo/main.py， 这 个 刚刚 从 repo.git 库 克隆 来 的 脚本 
文件 ， 继 续 进 行 初始 化 。 


克隆 android 的 清单 库 manifest.git (地 址 来 自 于 -u 参 数 ) 


克隆 的 清单 库 位 于 .repo/manifests.git 中 ， 本 地 克隆 


an | 


到 .repo/manifests。 清 单 文 件 .repo/manifest.xml 只 是 符号 链接 ， 它 指 


回 .repo/manifests/default.xml。 


询问 用 户 的 姓名 和 邮件 地 址 ， 如 果 和 Git 默 认 的 用 户 名 、 邮 件 地 址 
不 同 ， 则 记录 在 .repo/manifests.git 库 的 config 文 件 中 。 


命令 repo init 还 可 以 附带 --mirror 参 数 ， 以 建立 和 上 游 Android 的 版 
本 库 一 模 一 样 的 镜像 。 这 会 在 后 面 的 章节 介绍 。 


1. 从 哪里 下 载 repo.git? 


在 rep03| 导 脚本 的 前 几 行 ， 定义 了 默认 的 repo.git 的 版 本 库 位 置 及 
要 检 出 的 默认 分 文 。 


REPO_URL="'git://android.git.kernel.org/tools/repo.git'" 
REPO_REV="'stable' 


如 果 不 想 从 默认 URL 地 址 中 获取 repo， 或 者 不 想 获 取 稳 定 版 
(stable 分 支 ) 的 repo， 可 以 在 repo init 子 命令 中 通过 下 面 的 参数 覆盖 默 
认 的 设置 ， 从 指定 的 源 地 址 克隆 repo 代 码 库 : 


参数 --repo-url， 用 于 设 定 repo 的 版 本 库 地 址 。 
参数 --repo-branch， 用 于 设 定 要 检 出 的 分 文 。 


参数 --no-repo-verify， 设 定 不 要 对 repo 的 里 程 碑 签名 进行 严格 的 验 
证 。 


实际 上 上， 完成 repo.git 版 本 库 的 克隆 ， 这 个 repo 引 导 脚 本 束 江 即 才 
尽 了 ，repo init 命 令 的 后 续 处 理 (以 及 其 他 子 命令 ) 都 交 给 刚刚 克隆 出 
来 的 .reporepo/mmain.py 来 继续 执行 。 


2. 清 单 库 是 什么 ?从 哪里 下 载 ? 


清单 库 实际 上 只 包含 一 个 default.xml 文 件 。 这 个 XML 文 件 定 义 了 
多 个 版 本 库 和 本 地 地 址 的 映 喘 关 系 ， 和 是 repo 工 作 的 指引 文件 。 所 以 在 
使 用 repo 引 导 脚 本 进行 初始 化 的 时 候 ， 必 须 通过 -u 参 数 指定 清单 库 的 
源 地 址 。 


清单 库 的 下 载 ， 是 通过 repo init 命 令 初始 化 时 ， 用 -u 参 数 指定 清单 
库 的 位 置 。 例 如 repo 针 对 Android 代 码 库 进行 初始 化 时 执行 的 命令 : 


$repo init-u git://android.git.kernel.org/platform/manifest .git 
rep03| 守 脚本 的 init 子 命令 可 以 使 用 下 列 和 清单 库 相 天 的 参数 : 
参数 -u (--manifest-url) : 设 定 清单 库 的 Git 服 务 器 地 址 。 
参数 -b (--manifest-branch) : 检 出 清单 库 的 特定 分 支 。 


参数 --mirror 只 在 repo 第 一 次 初始 化 的 时 候 使 用 ， 以 和 Android 服 
务 器 同样 的 结构 在 本 地 建立 镜像 。 


参数 -m (--manifest-name) : 当 有 多 个 清单 文件 时 ， 可 以 指定 清 
单 库 的 某 个 清单 文件 为 有 效 的 清单 文件 。 默 认为 default,xml。 


repo 初 始 化 命令 (repo init) 可 以 执行 多 次 : 


不 市 参数 地 执行 repo init， 从 上 游 的 清单 库 获 取 新 的 清单 文件 


default.xml ° 


使 用 参数 -u (--manifest-url) 执行 repo init， 会 重新 设 定 上 游 的 清 
单 库 地 址 ， 并 重新 邮 步 。 


使 用 参数 -b (--manifest-branch) 执行 repo init， 会 使 用 清单 库 的 不 
同 分 支 ， 以 便 在 使 用 repo sync 时 将 项 目 同步 到 不 同 的 里 程 碑 。 


但 是 不 能 使 用 --mirror 命 令 ， 该 命名 只 能 在 第 一 次 初始 化 时 执行 。 
那么 如 何 将 已 经 按照 工作 区 模式 同步 的 版 本 库 转 换 为 镜像 模式 呢 ? 后 
面 会 看 到 一 个 解决 方案 。 


25.4 清单 库 和 清单 文件 


执行 完 repo init 之 后 ， 工 作 目 录 内 空空 如 也 。 实 际 上 有 一 个 .repo 目 
录 。 在 该 目录 下 除了 一 个 包含 repo 实 现 的 repo 库 克隆 外 ， 束 是 manifest 
库 的 克隆 ， 以 及 一 个 符号 链接 ， 链 接 到 清单 库 中 的 default.xml 文 件 。 


$1s-1F.repo/ 

drwxr-xr-x 3 jiangxin jiangxin 4096 2010-10-11 18:57 manifests/ 

drwxr-xr-x 8 jiangxin jiangxin 4096 2010-10-11 10:08 
manifests.git/ 

lrwxrwxrwx 1 jiangxin jiangxin 21 2010-10-11 10:07 manifest.xml- 
> 

manifests/default.xml 

drwxr-xr-x 7 jiangxin jiangxin 4096 2010-10-11 10:07 repo/ 


在 工作 目录 下 的 .repo/manifest.xml 文 件 束 是 Android 项 目的 众多 版 
本 库 的 清单 文件 。repo 命 令 的 操作 都 要 参考 这 个 清单 文件 。 


打开 清单 文件 会 看 到 如 下 内 容 : 


<? xml version="1.0" encoding="UTF-8"?> 
<manifest> 

<remote name="korg" 
fetch="git://android.git.kernel.org/" 
review="review.source.android.com"/> 


ONOPPODP 


<default revision="master" 

remote="korg"/> 

8 

9 <project path="build" name="platform/build"> 

10 <copyfile src="core/root.mk" dest="Makefile"/> 
11 </project> 

12 


13 <project path="bionic" name="platform/bionic"/> 


181 </manifest> 


这 个 文件 不 太 复杂 ， 是 吗 ? 
这 个 XML 的 顶级 元 素 是 manifest， 见 第 2 行 和 第 181 行 。 


第 3 行 通过 一 个 remote 元 素 ， 定 义 了 名 为 korg (kernel.org 缩 写 ) 的 
远程 版 本 库 ， 其 Git 库 的 基 址 为 git:/android.gitkernel.org/。 还 定义 了 代 
码 审核 服务 器 的 地 址 review.source.android.com。 还 可 以 定义 更 多 的 


remote 元 素 ， 这 里 只 定义 了 一 个 。 


第 6 行 用 于 设置 各 个 项 目 默 认 的 远程 版 本 库 (remote) 为 korg， 默 
认 的 分 支 为 master。 当然 各 个 项 目 (project 元 素 ) 可 以 定义 自己 的 
remote 和 revision 有 覆盖 该 默认 配置 。 


第 9 行 定义 了 一 个 项 目 ， 该 项 目的 远程 版 本 库 相 对 路 径 为 : 
platform/build， 在 工作 区 克隆 的 位 置 为 : build 。 


第 10 行 ， 即 project 元 素 的 子 元 素 copyfile， 定 义 了 项 目 克 隆 后 的 一 
个 附加 动作 : 从 core/root.mk 挡 贝 文件 至 Makefile 。 


第 13 行 后 续 的 100 多 行 定义 了 其 他 160 个 项 目 ， 都 是 采用 类 似 的 
project 元 素 语 法 。name 参 数 定义 远程 版 本 库 的 相对 路 人 径 ，path 参 数 定 
义 克 隆 到 本 地 工作 区 的 路 径 。 


还 可 以 出 现 manifest-server 元 素 ， 其 url 属 性 定义 了 通过 XMLRPC 提 
供 实时 更 产 清 单 的 服务 右 URL。 只 有 当 执 行 repo sync--smart-sync 的 时 
候 才 会 检查 该 值 ， 并 用 动态 获取 的 manifest 上 覆盖 掉 默 认 的 清单 。 


25.5 同步 项 目 


在 工作 区 执行 下 面 的 命令 ， 会 参照 .repo/manifest.xml 清 单 文件 ， 
将 项 目 所 有 相关 的 版 本 库 全 部 克隆 出 来 。 不 过 最 好 请 在 读 完 本 节 内 容 
之 后 再 尝试 执行 这 条 命令 


$repo sync 


对 于 Android， 这 个 操作 需要 通过 网 络 传递 接近 2 个 GB 的 内 容 ， 如 
果 市 宽 不 是 很 高 的 话 ， 可 能 会 伦 挥 几 个 小 时 甚至 是 一 天 的 时 间 。 


也 可 以 仅 克 隆 感 兴趣 的 项 目 ， 在 repo sync 后 面 跟 上 项 目的 名 称 。 
项 目的 名 称 来 目 于 .repo/manifest.xml 这 个 XML 文件 中 project 元 素 的 
name 属 性 值 。 例 如 元 隆 platform/build 项 目 : 


$repo sync platform/build 


repo 有 一 个 功能 可 以 在 这 里 展示 ， 就 是 repo 文 持 通过 本 地 清单 对 
默认 的 清单 文件 进行 补充 及 徐 盖 。 即 可 以 在 .repo 目 录 下 创建 
local_manifest.xml 文 件 ， 其 内 容 会 和 .repo/manifest,xml 文 件 的 内 容 进 行 
合并 。 


在 工作 目录 下 运行 下 面 的 命令 可 以 创建 一 个 本 地 清单 文件 。 这 个 
本 地 定制 的 清单 文件 来 目 默 认 文件 ， 但 是 删除 了 remote 元 素 和 default 
元 素 ， 并 将 所 有 的 project 元 素 都 重合 名 为 remove-project 元 素 。 这 实际 
相当 于 对 原 有 的 清单 文件 * 取 反 ”。 


$curl-L-k\ 
http://www.ossxp.com/doc/gotgit/download/ch25/manifest- 
revert.xsilt\ 
>manifest-revert.xsilt 
$xsltproc manifest-revert.xsilt.repo/manifest.xml 
> .repo/local manifest.xml 


用 下 面 的 这 条 命令 可 以 看 到 repo 运 行 时 实际 获取 到 的 清单 。 这 个 
清单 来 自 于 .repo/manifest.xml 和 .repo/local_manifest.xml 两 个 文件 的 汇 


属 o 


$repo manifest-o- 
当 执 行 repo sync 命 令 时 ， 实 际 上 束 是 依据 合并 后 的 请 单 文件 进行 


同步 。 如 琳 清 单 中 的 项 目 被 目 定 义 清单 全 部 “ 取 反 ”*， 执 行 同步 束 不 会 
同步 任何 项 目 ， 甚 至 会 删除 已 经 完成 同步 的 项 目 。 


本 地 定制 的 清单 文件 local_manifest.xml 支 持 前 面 介绍 的 清单 文件 
的 所 有 语法 ， 需 要 注意 的 是 : 


不 能 出 现 重复 定义 的 remote 元 素 。 这 就 是 为 什么 上 面 的 脚本 要 删 
除 来 自 默 认 manifest.xml 的 remote 元 素 。 


不 能 出 现 default 元 素 ， 因 为 全 局 只 能 有 一 个 。 


不 能 出 现 重复 的 project 定 义 (name 属 性 不 能 相同 ) ， 但 是 可 以 通 
过 remove-project 元 素 将 默认 清单 中 定义 的 project 删 除 然后 再 重新 定 
义 o 


试 着 编辑 .repo/local_manifest,xml， 在 其 中 再 添加 几 个 project 元 
素 ， 然 后 试 着 用 repo sync 命 令 进 行 同步 。 


25.6 ”建立 Android 代 码 库 本 地 镜像 


Android 为 企业 提供 一 个 新 的 市 场 ， 无 论 企业 大 小 都 处 于 同一 个 起 
跑 线 上 。 研 究 Android 尤 其 是 Android 系 统 核心 或 驱动 的 开发 ， 首 先 要 
做 的 就 是 通过 本 地 克隆 建立 一 套 Android 版 本 库 管 理 机 制 。 因 为 
Android 的 代码 库 是 那么 庞杂 ， 如 果 一 个 开发 团队 每 个 人 都 去 执行 repo 
init-u， 再 执行 repo sync 从 Android 服 务 器 克隆 版 本 库 的 话 ， 多 大 的 网 络 
带宽 式 怕 都 不 够 用 。 唯 一 的 办 法 是 在 本 地 建立 一 个 Android 版 本 库 的 镜 
像 。 


建立 本 地 镜像 非常 简单 ， 融 是 在 执行 repo initru 初 始 化 的 时 候 ， 附 
和 带 上 --mirror 参 数 。 
$mkdir android-mirror-dir 
$cd android-mirror-dir 
$repo init--mirror-u 
git://android.git.kernel.org/platform/manifest.git 
之 后 执行 repo sync 就 可 以 从 安装 Android 的 Git 服 务 器 方式 来 组 织 版 
本 库 ， 创 建 一 个 Android 版 本 库 镜 像 了 。 


实际 上 附带 了 --mirror 参 数 执 行 repo init-u 命 令 ， 会 在 克隆 
的 .repo/manifests.git 下 的 config 中 记录 配置 信息 .: 


[repo] 
mirror=true 


1. 从 Android 的 工作 区 到 代码 库 镜 像 


在 初始 化 repo 工 作 区 时 ， 使 用 不 带 --mirror 参 数 的 repo init-u， 并 完 
成 代码 同步 后 ， 如 果 再 次 执行 repo init 并 附带 了 --mirror 参 数 ，repo 会 报 
错 退 出 : "fatal:--mirror not supported on existing client"。 实 际 上 --mirror 


参数 只 能 对 尚未 初始 化 的 repo 工 作 区 执行 


那么 如 采 之 前 没有 用 镜像 的 方法 同步 Android 版 本 库 ， 难 道 要 为 创 
建 代码 库 镜 像 再 重新 执行 一 次 repo 同 步 吗 ? 要 知道 重新 同步 一 份 
Android 版 本 库 征 非常 慢 的 。 我 吏 遇 到 了 这 个 问题 。 


不 过 既然 有 manifest,xml 文 件 ， 完 全 可 以 对 工作 区 进行 反 向 操作 ， 
将 工作 区 转换 为 镜像 服务 器 的 结构 。 下 面 就 是 一 个 示例 脚本 ， 可 以 从 
本 书 在 Github 上 的 相关 版 本 库 中 下载。 这 个 脚本 利用 了 已 有 的 repo 代 
码 进行 实现 ， 所 以 看 着 很 简洁 。8-) 


脚本 work2mirrorpy 如 下 : 


#!/UusSr/bin/python 

#-*-coding:utf-8-*- 

import os,sys,shutil 
cwd=o0s.path.abspath(os.path.dirname(__file _)) 
repodir=os.path.join(cwd,'.repo') 

S_repo= 'repo'， 

TRASHDIR="'old_ work_tree' 

if not os.path.exists(os.path.join(repodir,Ss_repo)): 


print>>sys.stderr,"Must run under repo work_dir root." 
sys.exit(1) 
sys.path.insert(0,os.path.join(repodir,S_repo)) 
from manifest_ xml] import XmlLManifest 
manifest=XmlManifest(repodir) 
if manifest,.IsMirror: 
print>>sys.stderr,"Already mirror,exit." 
sys.exit(1) 
trash=os.path.join(cwd,TRASHDIR) 
for project in manifest.projects.itervalues(): 
# 将 旧 的 版 本 库 路 径 移动 到 镜像 模式 下 新 的 版 本 库 路 径 
newgitdir=os.path.join(cwd, '%s.git' %project,name ) 
if os.path.exists(project.gitdir)and project.gitdir!=newgitdir: 
if not os.path.exists(os.path.dirname(newgitdir)): 
os.makedirs(os.path.dirname(newgitdir)) 
print "Rename%s to%s." %(project.gitdir,newgitdir) 
os.rename(project.gitdir,newgitdir) 
# 将 工作 区 移动 到 待 删除 目录 
if project.worktree and os.path.exists(project.worktree): 
newworktree=os.path.join(trash,project.relpath) 
if not os.path.exists(os.path.dirname(newworktree)): 
os.makedirs(os.path.dirname(newworktree)) 
print "Move old worktree%s to%s." % 
(project .worktree, newworktree) 
os.rename(project .worktree,newworktree) 
if os,path.exists(os.path, join(newgitdir， config ' ) ) : 
# 修 改版 本 库 的 配置 
os.chdir(newgitdir) 
os.system("git config core.bare true") 
os.sSystem("git config remote.korg.fetch 
'+refs/heads/*:refs/heads/*' ") 
# 删 除 remotes 分 支 , 因为 作为 版 本 库 镜 像 不 需要 remote 分 支 
if os.path.exists(os.path.join(newgitdir, 'refs', 'remotes')): 
print "Delete" +0os.path.join(newgitdir,'refs','remotes') 
shutil.rmtree(os.path.join(newgitdir,'refs','remotes')) 
# 设 置 menifest 为 镜像 
mp=manifest.manifestProject 
mp.config.SetString('repo.mirror','true') 


使 用 方法 很 简单 ， 只 要 将 脚本 放 在 Android 工 作 区 下 执行 束 可 以 
了 。 执 行 完毕 会 将 原 有 工作 区 的 目 隶 移动 到 old_work_tree 于 目录 下 ， 


在 确认 原 有 工作 区 没有 未 提交 的 数据 后 ， 直 接 删除 old_work_tree 即 
可 。 


$python work2mirror .py 


2. 创 建新 的 清单 库 ， 或 者 修改 原 有 清单 库 


建立 了 Android 代 码 库 的 本 地 镜像 后 ， 如 采 不 对 manifest 请 单 版 本 
库 进 行 定制 ， 在 使 用 repo sync 同 步 代 码 的 上 时候， 仍然 使 用 Android 官 方 
的 代码 库 同 步 代 码 ， 就 会 使 得 本 地 的 镜像 版 本 库 形同虚设 。 解 决 办 法 
是 创建 一 个 自己 的 manifest 库 ， 或 者 在 原 有 清单 库 中 建立 一 个 分 文 加 以 
人 和 修改。 如果 创建 新 的 清单 库 ， 参 考 Android 上 游 的 manifest 清 单 库 进行 
创建 。 


[1] https://github.com/ossxp- 


com/gotgit/raw/master/download/ch25/work2mirror.py 


25.7 ”repo 的 命令 集 


repo 子 命令 实际 上 是 Git 命 令 的 或 简单 或 复杂 的 封 效 。 每 一 个 repo 
子 命令 都 对 应 于 repo 源 码 树 中 subcmds 目 录 下 的 一 个 同名 的 Python 文 
件 。 每 一 个 repo 子 命令 都 可 以 通过 下 面 的 命令 获得 帮助 。 


repo help<command> 


过 阅读 代码 ， 可 以 更 加 深入 地 了 解 repo 子 命令 的 封闭 


1.repo init 命 令 


repo init 子 命令 主要 完成 检 出 清单 版 本 库 (manifest.git) ， 以 及 配 
置 Git 用 户 的 用 户 名 和 邮件 地 址 的 工作 。 


实际 上 ， 完 全 可 以 进入 到 .repo/manifests 目 录 ， 用 Git 命 令 操 作 清单 
库 。 对 manifests 的 修改 不 会 因为 执行 repo init 而 丢失 ， 除 非 是 处 于 未 跟 
踩 状态 。 


2.repo Sync 命令 


repo sync 子 命令 用 于 参照 清单 文件 克隆 或 同步 版 本 库 。 如 果 某 个 
项 目 版 本 库 尚 不 存在 ， 则 执行 repo sync 命 令 相 当 于 执行 git clone。 如 果 
项 目 版 本 库 已 经 存在 ， 则 相当 于 执行 下 面 的 两 个 命令 : 


git remote update 
相当 于 对 每 一 个 remote 源 执行 fetch 操 作 。 
git rebase origin/branch 


针对 当前 分 文 的 跟踪 分 文 执 行 rebase 操 作 。 不 采用 merge 而 是 采用 
rebase， 目 的 是 减少 提交 数量 、 方 便 评 审 (Gerrit) 。 


3.repo start 命 令 


repo start 子 命令 实际 上 是 对 git checkout-b 命 令 的 封装 。 为 指定 的 项 
目 或 所 有 项 目 〈“ 若 使 用 --al 参 数 ) ， 以 清单 文件 中 为 项 目 设 定 的 分 文 
或 里 程 碑 为 基础 ， 创 建 特性 分 文 。 特 性 分 文 的 名 称 由 命令 的 第 一 个 参 
数 指定 。 相 当 于 执行 checkout-b。 
用 法 如 下 : 
repo start<newbranchname>[--all|<project>...] 
命令 


4.repo StatusR 


repo status 子 命令 实际 上 是 对 git diff-index、git diff-files 命 令 的 封 
装 ， 同 时 显示 暂 存 区 的 状态 和 本 地 文件 修改 的 状态 。 


用 法 如 下 : 


repo status[<project>...] 


示例 输出 : 


project repo/branch devwork 
-m subcmds/status.py 


上 面 的 示例 输出 显示 了 repo 项 目的 devwork 分 支 的 修改 状态 。 


每 个 小 市 的 陡 行 显示 项 目的 名 称 ， 以 及 所 在 分 文 的 名 称 。 


之 后 显示 该 项 目 中 文件 的 变更 状态 。 头 两 个 字母 显示 变更 状态 ， 
后 面 显示 文件 名 或 其 他 变更 信息 。 


第 一 个 字母 表示 和 暂 存 区 的 文件 修改 状态 。 

其 实 是 git-diff-index 命 令 输出 中 的 状态 标识 ， 用 大 写 显示 。 
O-: 没有 改变 

OA: 添加 〈 不 在 HEAD 中 ， 在 暂 存 区 ) 

OM: 修改 (在 HEAD 中 ， 在 和 暂 存 区 ， 内 容 不 同 ) 

OD: 删除 (在 HEAD 中 ， 不 在 暂 存 区 ) 


OR: 重 命名 (不 在 HEAD 中 ， 在 暂 存 区 ， 路 径 修改 ) 


OC: 拷贝 (不 在 HEAD 中 ， 在 暂 存 区 ， 从 其 他 文件 搁 贝 ) 
OT: 文件 状态 改变 〈 在 HEAD 中 ， 在 暂 存 区 ， 内 容 相 同 ) 


OU: 未 合并 ， 需 要 冲突 解决 


第 二 个 字母 表示 工作 区 文件 的 更 改 状态 。 


其 实 古 git-diff-files 命 令 输 出 中 的 状态 标识 ， 用 小 写 显示 。 


O-: 新 /未 知 (不 在 暂 存 区 ， 在 工作 区 ) 


Om: 修改 (在 暂 存 区 ， 在 工作 区 ， 被 修改 ) 


Od: 删除 (在 暂 存 区 ， 不 在 工作 区 ) 


两 个 表示 状态 的 字母 后 面 ， 显 示 文 件 名 信息 。 如 果 有 文件 重 命名 
还 会 显示 改变 前 后 的 文件 名 及 文件 的 相似 度 。 


5.repo checkout 命 令 


repo checkout 子 命令 实际 上 是 对 git checkout 命 令 的 封装 。 检 出 之 
前 由 repo start 创 建 的 分 支 。 


用 法 如 下 : 


repo checkout<branchname>[<project>...] 


6.repo branches 命 令 


repo branches 读 取 各 个 项 目的 分 支 列表 并 汇总 显示 。 该 命令 实际 
上 通过 直接 读 取 .git/refs 目 录 下 的 引用 来 获取 分 支 列表 ， 以 及 分 支 的 发 
布 状 态 


时 
4 。 
DA 可 


用 法 如 下 : 


repo branches[<project>...] 


输出 示例 : 


*P nocolor|in repo 
repo2| 


第 一 个 字段 显示 分 文 的 状态 : 是 否 当前 分 文 ， 分 文 是 否 发 布 到 代 


码 审核 服务 右上 ? 


第 一 个 字母 大 显示 星 号 (*) ， 则 含义 是 此 分 文 为 当前 分 文 。 


第 二 个 字母 看 为 大 写字 母 P， 则 含义 是 分 文 的 所 有 提交 都 发 布 到 
代码 审核 服务 厚 上 了 。 


第 二 个 字母 春 为 小 写字 母 p， 则 侣 义 是 只 有 部 分 提交 被 发 布 到 代码 
审核 服务 器 上 。 


铬 不 显示 P 或 p， 则 表明 分 支 尚 未 发 布 。 
第 三 个 等 展 为 分 文 各” 


第 三 个 字段 为 以 坚 线 (|) 开始 的 字符 串 ， 表 示 该 分 文 存在 于 哪些 
项 目 中 。 


Oin all projects 

该 分 文 处 于 所 有 项 目 中 。 

Oin project1 project2 

该 分 文 只 在 特定 项 目 中 定义 。 如 : projectl 、project2。 
Onot in project1 


该 分 文 不 存在 于 这 些 项 目 中 。 即 除了 project1 项 目 外 ， 其 他 项 目 都 
包含 此 分 文 。 


7.repo diff 命 令 


repo diff 子 命令 实际 上 是 对 git diff 命 令 的 封装 ， 用 于 分 别 显示 各 个 
项 目 工作 区 下 的 文件 差异 。 


用 法 如 下 : 


repo diff[<project>...] 


8.repo stage 命 令 


repo stage 子 命令 实际 上 是 对 git add--interactive 命 令 的 封装 ， 用 于 


挑选 各 个 项 目 工作 区 中 的 改动 (修改 、 添 加 等 以 加 入 和 暂 存 区 。 
用 法 如 下 : 
repo stage-i[<project>...] 
9.repo upload 命 令 


repo upload 相 当 于 git push， 但 是 义 有 很 大 的 不 同 。 执 行 repo 
upload 不 是 将 版 本 库 改动 推送 到 克隆 时 的 远程 服务 器 ， 而 是 推送 到 代 
码 审 查 服务 器 (由 Gerrit 软 件 架 设 ) 的 特殊 引用 上 ， 使 用 的 是 SSH 协 议 
(特殊 端口 ) 。 代 码 审核 服务 器 会 对 推送 的 提交 进行 特殊 人 处理， 将 新 
的 提交 显示 为 一 个 待 审核 的 修改 集 ， 并 进入 代码 审查 流程 。 只 有 当 审 
核 通 过 后 ， 才 会 合并 到 官方 正式 的 版 本 库 中 。 


repo upload[--re--cc]{[<project>]...|--replace<project>} 
参 类 他， 

-h, - -helLp 显 示 帮 助 信 息 。 
-t 发 送 本 地 分 支 名称 到 Gerrit 代 码 审核 服务 器 。 
--replace 发 送 此 分 文 的 更 新 补丁 集 。 注 意 使 用 该 参数 , 只 能 指定 一 个 项 目 。 
--re=REVIEWERS, - -reviewers=REVIEWERS 

要 求 由 指定 的 人 员 进 行 审核 。 


- -CCc=CC 同 时 发 送 通知 到 如 下 邮件 地 址 。 


确定 推送 服务 器 的 端口 


分 文 改 动 的 推送 是 发 给 代码 审核 服务 郁 ， 而 不 是 下 载 代码 的 服务 
吉 。 使 用 的 协议 是 SSH 协 议 ， 但 是 使 用 的 并 非 标 准 端口 。 如 何 确认 代 
码 审核 服务 右上 提供 的 特殊 SSH 端 口 呢 ? 


在 执行 repo upload 命 令 时 ，repo 会 通过 访问 代码 审核 web 服务 右 
的 /ssh_info 的 Un 获取 SSH 服 务 端口 ， 默 认为 29418。 这 个 端口 ， 就 是 
repo upload 发 起 推送 的 服务 絮 的 SSH 服 务 端 口 。 


修订 集 修改 后 重新 传送 
只 有 已 经 通过 repo upload 命 令 在 代码 审查 服务 絮 上 提交 了 一 个 修 
订 集 ， 才 会 得 到 一 个 修订 号 。 关 于 此 次 修订 的 相关 讨论 会 发 送 到 提交 


者 的 邮箱 中 。 如 采 修 订 集 有 误 没 有 通过 审核 ， 可 以 重新 修改 代码 ， 再 
次 回 代 码 审核 服务 右上 传 修订 集 。 


一 个 修订 集 修 改 后 再 次 上 传 ， 如 有 果 修 订 集 的 ID 不 变 那 将 是 非常 有 
用 的 ， 因 为 这 样 相 关 的 修订 集 都 在 代码 审核 服务 万 的 同一 个 界面 中 显 


小 ° 


在 执行 repo upload 时 会 弹出 一 个 编辑 界面 ， 提 示 在 方 括号 中 输入 
修订 集 编号 ， 人 否则 会 在 代码 审查 服务 右上 创建 新 的 ID。 有 一 个 办 法 可 


以 不 用 手工 输入 修订 集 ， 如 下 : 


repo upload--replace project_name 


当 使 用 --replace 参 数 后 ，repo 会 检查 本 地 版 本 库 名 为 
refs/published/branch_name 的 特殊 引用 (上 一 次 提交 的 修订 ) ， 获 得 其 
对 应 的 提交 SHA1 哈 希 值 。 然 后 在 代码 审核 服务 器 的 refs/changes/ 命 名 
空间 下 的 特殊 引用 中 寻找 和 提交 SHA1 哈 希 值 匹配 的 引用 ， 找 到 的 匹配 
引用 其 名 称 中 就 所 包含 有 变更 集 ID ， 直 接 用 此 变更 集 ID 作 为 新 的 变更 
集 ID 提 交 到 代码 审核 服务 器 。 


Gerrit 服 务 器 魔法 


repo upload 命 令 执 行 推送 ， 实 际 上 会 以 类 似 如 下 的 命令 行 格式 进 
行 调用 : 
git push--receive-pack='gerrit receive-pack--reviewer 


charlie@example.com'\ 
ssh://review.example.com:29418/project HEAD:refs/for/master 


Gerrit 服 务 器 接收 到 git push 请 求 后 ， 会 自动 将 对 分 支 的 提交 转换 
为 修订 集 ， 显 示 于 Gerrit 的 提交 审核 界面 中 。Gerrit 的 魔法 破解 的 天 键 
点 就 在 于 git push 命 令 的 --receive-pack 参 数 。 即 交 由 gerrit-receive-pack 
命令 执行 提交 ， 进 入 非 标准 的 git 处 理 流程 ， 将 提交 转换 为 在 
refs/changes 命 名 空间 下 的 引用 ， 而 不 在 refs/for 命 名 空间 下 创建 引用 。 


10.repo download 命 令 


repo download 命 令 主要 用 于 代码 审核 者 下 载 和 评估 页 献 者 提交 的 
修订 。 贡 献 者 的 修订 在 Git 版 本 库 中 以 refs/changes/< changeid> /< 
patchset > 引用 方式 命名 (默认 的 patchset 为 1)y” ， 和 其 他 Git 引 用 一 样 ， 
用 git fetch 获 取 ， 该 引用 所 指向 的 最 新 的 提交 束 是 页 献 者 待 审核 的 修 
订 。 使 用 repo download 命 令 实际 上 就 是 用 git fetch 获 取 到 对 应 项 目的 
refs/changes/<changeid>>/patchset> 引 用 ， 并 自动 切换 到 对 应 的 引用 
上 8 


用 法 如 下 : 


repo download{project change[/patchset]}... 


11.repo rebase 命 令 


repo rebase 子 命令 实际 上 是 对 git rebase 命 令 的 封装 ， 该 命令 的 参数 


也 作为 git rebase 命 令 的 参数 ， 但 -i 参数 仅 当 对 一 个 项 执行 时 才 有 效 。 


用 法 如 下 : 
命令 行 :repo rebase{[<project>.,..]|-i<project>...} 
参数 : 
-h, - -help 显 示 帮 助 并 退出 
-i, --interactive 交 互 式 的 变 基 ( 仅 对 一 个 项 目 时 有 效 ) 
-f, --force-rebase 向 git rebase 命 令 传递 - -force-rebase 人 参数 


--no-ff 向 git rebase 命 令 传递 -no -ff 参数 
-q, --quiet 向 git rebase 命 令 传 递 - -quiet 参 数 
--autosquash 向 git rebase 命 令 传递 - -autosquash 参 数 


--whitespace=WS 疝 git rebase 命 令 传递 - -whitespace 参 数 


12.repo prune 命 令 


repo prune 子 命令 实际 上 是 对 git branch-d 命 令 的 封装 ， 该 命令 用 于 


扫描 项 目的 各 个 分 文 ， 并 删除 已 经 合并 的 分 文 。 


用 法 如 下 : 


repo prune[<project>...] 


13. repo abandon 命令 

相 比 repo prune 命令 ，repo abandon 命令 更 具 破 坏 性 ， 因 为 repo abandon 蚌 
对 git branch -D 命令 的 封装 。 读 命令 非常 危险 ， 将 直接 删除 分 支 ， 请 愤 用 .。 

用 法 如 下 : 

repo abandon <branchname> [<project>,..] 


14. 其 他 命令 
Drepo grep 
相当 于 对 git grep 的 封装 ， 用 于 在 项 目 文件 中 进行 内 容 查 找 。 
Drepo smartsync 
相当 于 用 -~s 参数 执行 repo sync。 
Drepo forall 
迭代 器 ， 可 以 对 repo 管理 的 项 目 进行 迭代 。 
Drepo manifest 
显示 manifest 文件 内 容 。 
口 repo Version 
显示 repo 的 版 本 号 。 
Drepo selfupdate 
用 于 repo 自身 的 更 新 。 如 果 提 供 --repo-upgraded 参数 ， 还 会 更 新 各 个 项 目的 钧 子 脚 本 。 


25.8 ”repo 命 令 的 工作 沉 


图 25-1 是 repo 的 工作 流 ， 每 一 个 代码 贡献 都 起 始 于 repo start 创建 的 本 地 工作 分 
支 ， 最 终 都 Lrepo uploag 命令 将 代码 补丁 发 布 到 代码 审核 服务 器 。 


图 25-1 repo 工作 流 


25.9 ”好 东西 不 能 Android 独 肌 


通过 前 面 的 介绍 能 够 体会 到 repo 的 精巧 一 一 repo 巧 妙 地 实现 了 多 
Git 版 本 库 的 管理 。 因 为 repo 使 用 了 清单 版 本 库 ， 所 以 repo 这 一 工具 并 
没有 被 局 限于 Android 项 目 ， 可 以 在 任何 项 目 中 使 用 。 下 面 束 介绍 三 种 
repo 的 使 用 模式 ， 将 repo 引 入 自己 的 项 目 ( 非 Android 项 目 ) 中 ， 其 中 
第 三 种 repo 使 用 模式 是 用 我 改造 后 的 repo， 实 现 了 脱离 Gerrit 服 务 器 进 
行 推送 。 


25.9.1 ”repo+Gerrit 模 式 


repo 和 Gerrit 是 Android 代 码 管理 的 两 大 文 柱 。 正 如 前 面 在 repo 工 作 
流 中 介绍 的 ， 部 分 的 repo 命 令 从 Git 服 务 颖 读 取 ， 这 个 Git 服 务 絮 可 以 是 
只 读 的 版 本 库 控 制服 务 器 ， 还 有 部 分 repo 命 令 (repo upload 、repo 
download) 访问 的 则 是 代码 审核 服务 器 ， 其 中 repo upload 命 令 还 要 癌 
代码 审核 服务 右 进 行 git push 操 作 。 


在 使 用 未 经 改动 的 repo 来 维护 目 己 的 项 目 (多 个 版 本 库 组 成 ) 
时 ， 必 须 搭建 Gerrit 代 码 审 核 服务 器 。 


搭建 项 目的 版 本 控制 系统 环境 的 一 般 方法 为 : 


用 Git 协 议 或 HTTP 协 议 搭建 Git 服 务 器 。 具 体 搭 建 方法 参见 第 5 
篇 “搭建 Git 服 务 咒 ”的 相关 章节 。 


导入 repo.git 工 具 库 。 非 必须 ， 只 是 为 了 减少 不 必要 的 互联 网 操 
作 。 
还 可 以 在 内 部 HITP 服 务 器 维护 一 个 定制 的 repo 引 导 脚 本 ， 非 必 


须 。 


建立 Gerrit 代 码 审核 服务 右 。 会 在 第 5 篇 “第 32 章 Gerrit 代 但 审核 服 


务 器 ”中 介绍 Gerrit 的 安装 和 使 用 。 
一 一 创建 相关 的 子 项 目 代 码 库 。 


建立 一 个 manifest.git 清 单 库 ， 其 中 remote 元 素 的 fetch 属 性 指 癌 只 
Git 服 务 妖 地 址 ，review 属 性 指向 代码 审核 服务 颖 地 址 。 示 例如 下 : 


<? xml version="1.0" encoding="UTF-8"? > 
<manifest> 

<remote name="example" 
fetch="git://git.example.net/" 
review="review.example.net"/> 

<default revision="master" 
remote="example"/> 


过 
二 


25.9.2 repo 无 审核 模式 


Gerrit 代 码 审核 服务 硕 部 署 比较 麻烦 ， 更 不 要 说 因为 Gerrit 用 户 界 
面 的 学 习 和 用 户 使 用 习惯 的 更 改 而 市 来 的 困难 了 。 在 一 个 固定 的 团队 
内 部 使 用 repo 可 能 真 的 没有 必要 使 用 Gerrit， 因 为 团队 成 员 痢 应 该 熟悉 
Git 的 操作 ， 团 队 成 员 的 编程 能 力 都 可 人 和信， 单元 测试 质量 由 提交 者 保 
证 ， 和 集成 测试 由 单独 的 测试 团队 进行 ， 即 团队 拥有 一 套 完 整 、 成 型 的 
研发 工作 流 ， 引 入 Gerrit 并 非 必 要 。 


脱离 了 Gemrrit 服 务 器 ， 直 接 跟 Git 服 务 器 打交道 ，repo 可 以 工作 吗 ? 
是 的 ， 可 以 利用 repo forall 和 迭代 属实 现 多 项 目 代 码 的 PUSH， 其 中 有 如 
下 关键 点 需要 重点 关注 。 


repo start 命 令 创建 本 地 分 文 时 ， 需 要 使 用 和 上 游 同 样 的 分 文 名 。 


如 果 使 用 不 同 的 分 文 名 ， 上 传 时 需要 提供 复杂 的 引用 描述 。 下 面 
的 示例 先 通 过 repo 


manifest 命 令 确认 上 游 清 单 库 默 认 的 分 文 名 为 master， 再 使 用 该 分 
支 名 (master) 


作为 本 地 分 支 名 执行 repo start。 示 例如 下 : 


$repo manifest-o-|grep default 


<default remote="bj" revision="master"/> 
$repo start master--all 


推送 不 能 使 用 repo upload， 而 需要 使 用 git push 命 令 。 
可 以 利用 repo forall 送 代 絮 实现 批 命令 方式 执行 。 例 如 : 


$repo forall-c git push 


如 果 清 单 库 中 的 上 游 git 库 地 址 用 的 是 只 读 地 址 ， 需 要 为 本 地 版 本 
库 一 一 更 改 上 游 版 本 库 地 址 。 


可 以 使 用 forall 和 迭代 右 ， 批 量 为 版 本 库 设 置 git push 时 的 版 本 库 地 
址 。 下 面 的 命令 使 用 的 环境 变量 $8REPO_PROJECT 是 实现 批量 设置 的 
关键 。 
$repo forall-c\ 


'git remote set-url--push bj 
android@bj .ossxp.com:android/${REPO_PROJECT} .git'" 


25.9.3 ”改进 的 repo 无 审核 模式 


前 面 介 绍 的 使 用 repo forall 达 代 需 实现 在 无 审核 服务 器 情况 下 加 上 
游 推 送 提交 ， 只 是 权宜 之 计 ， 尤 其 是 用 repo start 建 立 工 作 分 文 要 求 和 
上 游 一 致 ， 实 在 是 有 点 强人 所 难 。 


我 改造 了 repo， 增 加 了 两 个 新 的 子 命令 repo config 和 repo push， 让 
repo 可 以 脱离 Gerrit 服 务 絮 直接 向 上 游 推 送 。 代 码 托 管 在 Github 上 : 
http://github.com/ossxp-com/repo。 下 面 人 简单 地 介绍 一 下 如 何 使 用 改造 
之 后 的 repo。 


1. 下 载 改 造 后 的 repo3| 导 脚本 


建议 使 用 改造 后 的 repo3 引 1 导 脚 本 车 换 原 脚本 ， 否 则 在 执行 repo init 


命令 时 需要 提供 额外 的 --no-repo-verify 参 数 、--repo-url 和 --repo-branch 


$curl-L-k http://github.com/ossxp-com/repo/raw/master/repo> 
~/bin/repo 
$chmod a+x~/bin/repo 


2. 用 repo 从 Github 上 检 出 测试 项 目 


如 果 安 装 了 改造 后 的 repo 引 导 脚 本 ， 使 用 下 面 的 命令 初始 化 repo 
及 清单 库 。 


$mkdir test 

$cd test 

$repo init-u git://github.com/ossxp-com/manifest.git 
$repo sync 


如 有 果 用 的 是 标准 的 (未 经 改造 的 ) repo 引 导 脚 本 ， 使 用 下 面 的 命 


$mkdir test 

$cd test 

$repo init--repo-url=git://github.com/ossxp-com/repo.git\ 
--repo-branch=master--no-repo-verify\ 

-U git://github.com/ossxp-com/manifest.git 

$repo sync 


当 子 项 目 代码 全 部 同步 完成 后 ， 执 行 make 命 令 。 可 以 看 到 各 个 子 
项 目的 版 本 及 清单 库 的 版 本 。 
$make 
Version of test1:1:0.2-dev 


Version of test2:2:0.2 
Version of manifest:current 


3. 用 repo config 命 令 设 置 pushurl 


现在 如 果 进 入 到 各 个 子 项 目 目录 ， 是 无 法 成 功 执行 git push 命 令 
的 ， 因 为 上 游 Git 库 的 地 址 是 一 个 只 读 访问 的 URL， 无 法 提供 写 服务 。 


可 以 用 新 增 的 repo config 命 令 设置 执行 git push 时 的 URL 地 址 。 


$repo config repo.pushurl ssh://git@github.com/ossxp-com/ 


设置 成 功 后 ， 可 以 使 用 repo config repo.pushurl 查 看 设置 。 


$repo config repo.pushurl 
ssh://git@github.com/ossxp-com/ 


4. 创 建 本 地 工作 分 文 
使 用 下 面 的 命令 创建 一 个 工作 分 文 jiangxin。 


$repo start jiangxin--all 


使 用 repo branches 命 令 可 以 查看 当前 所 有 的 子 项 目 都 属于 jiangxin 
分 文 。 


$repo branches 
*jiangxin|in all projects 


参照 下 面 的 方法 修改 test/test1 子 项 目 。 对 test/test2 项 目 也 作 类 似 修 


Bs 


$cd test/test1 

$echo "1:0.2-jiangxin">version 
$git diff 

diff--git a/version b/version 
index 37c65f8..a58ac04 100644 
---a/version 


+++b/version 

@@-1+1@@ 

-1:0.2-dev 

+1:0.2-jiangxin 

$repo status 

#0n branch jiangxin 

project test/test1i/branch jiangxin 
-Mm 

version 

$git add-u 

$git commit-m "0.2-dev->0.2-jiangxin" 


执行 make 命 令 ， 看 看 各 个 项 目的 改变 。 


$make 

Version of test1:1:0.2-jiangxin 
Version of test2:2:0.2-jiangxin 
Version of manifest:current 


5.PUSH 人 到 远程 服务 器 
直接 执行 repo push 束 可 以 推送 各 个 项 目的 改动 。 


$repo push 


如 果 有 多 个 项 目 同时 进行 了 改动 ， 为 了 避免 出 错 ， 会 弹出 编辑 器 
显示 因为 包含 改动 而 需要 推送 的 项 目 列表 。 


#Uncomment the branches to upload: 

# 

#project test/test1/: 

#branch jiangxin(1 commit,Mon Oct 25 18:04:51 2010+0800): 
#4f941239 0.2-dev->0.2-jiangxin 

# 

#project test/test2/: 

#branch jiangxin(1 commit,Mon Oct 25 18:06:51 2010+0800 ) : 


#86683ece 0.2-dev->0.2-jiangxin 


每 行 前 面 的 井 号 都 是 注释 会 被 忽略 。 将 布 望 推 送 的 分 文 前 的 注释 
去 挥 ， 束 可 以 将 该 项 目的 分 支 执行 推送 动作 。 下 面 的 操作 中 把 其 中 的 
两 个 分 文 的 注释 都 去 掉 了 ， 这 两 个 项 目 当前 分 文 的 改动 会 push 到 上 游 


服务 右 。 


#Uncomment the branches to upload: 

# 

#project test/test1/: 

branch jiangxin(1 commit,Mon Oct 25 18:04:51 2010+0800): 
#4f941239 0.2-dev->0.2-jiangxin 

# 

#project test/test2/: 

branch jiangxin(1 commit,Mon Oct 25 18:06:51 2010+0800): 
#86683ece 0.2-dev->0.2-jiangxin 


保存 退出 “如 果 使 用 vi 编辑 器 ， 输 入 <ESC> : wd 执行 保存 退 
出 ) 后 ， 马 上 开始 对 选择 的 各 个 项 目 执行 git push 。 


Counting objects:5, done， 

Delta compression using up to 2 threads. 
Compressing objects:100%(2/2),done. 

Writing objects:100%(3/3),293 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 

To ssh://git@github.com/ossxp-com/test1.git 
27aee23..4f94123 jiangxin->master 

Counting objects:5, done. 

Writing objects:100%(3/3),261 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 

To ssh://git@github.com/ossxp-com/test2.git 
7f0841d. .86683ec jiangxin->master 
[OK]test/test1/jiangxin 
[OKl]test/test2/jiangxin 


从 推送 的 命令 输出 可 以 看 出 来 ， 本 地 的 工作 分 文 jiangxin 的 改动 被 


推送 到 远程 服务 器 的 master 分 文本 地 工作 分 支 跟 踪 的 上 游 分 支 ) 
江 


再 次 执行 repo push， 会 显示 没有 项 目 需要 推送 。 


$repo push 
no branches ready for upload 


6. 在 远程 服务 器 创建 新 分 文 


如 果 想 在 服务 器 上 创建 一 个 新 的 分 文 ， 该 如 何 操作 昵 ? 如 下 使 用 - 
-new_branch 参 数 调 用 repo push 命 令 。 


$repo start feature1--al1 
$repo push- -new_branch 


经 过 同样 的 编辑 操作 之 后 自动 调用 git push， 在 服务 器 上 创建 新 分 
支 featurel 。 


Total O(delta 0),reused 0O(delta 0) 

To ssh://git@github.com/ossxp-com/test1.git 
*[new branch]feature1i->featurel1 

Total O(delta 0),reused 0O(delta 0) 

To ssh://git@github.com/ossxp-com/test2.git 
*[new branch]feature1->featurel1 
[OK]test/test1i/feature1 
[OK]test/test2/feature1 


用 git ls-remote 命 令 查看 远程 版 本 库 的 分 文 ， 会 发 现 远程 版 本 库 中 
已 经 建立 了 新 的 分 文 。 
$git ls-remote git://github.com/ossxp-com/test1i.git refs/heads/* 
4f9412399bf8093e880068477203351829a6b1fb refs/heads/feature1 


4f9412399bf8093e880068477203351829a6b1fb refs/heads/master 
b2b246b99ca504f141299ecdbadb23faf6918973 refs/heads/test-0.1 


注意 到 featurel 和 master 分 支 引 用 指 癌 了 相同 的 SHA1 哈 希 值 ， 这 是 
因为 feature1 分 文 是 直接 从 master 分 文 创建 的 。 


7. 通 过 不 同 的 清单 库 版 本 ， 切 换 到 不 同 分 文 


换 用 不 同 的 请 单 库 ， 需 要 建立 新 的 工作 区 ， 并 且 在 执行 repo init 
时 ， 通 过 -b 参 数 指定 清单 库 的 分 文 。 


$mkdir test-0.1 

$cd test-0.1 

$repo init-u git://github.com/ossxp-com/manifest.git-b test-0.1 
$repo sync 


当 子 项 目 代 码 全 部 同步 完成 后 执行 make 命 令 。 可 以 看 到 各 个 子 项 
目的 版 本 及 清单 库 的 版 本 不 同 于 之 前 的 输出 。 
$make 
Version of test1:1:0.1.4 


Version of test2:2:0.1.3-dev 
Version of manifest:current-2-g12f9080 


可 以 用 repo manifest 命 令 来 查看 清单 库 。 


$repo manifest-o- 

<? xml version="1.0" encoding="UTF-8"? > 

<manifest> 

<remote fetch="git://github.com/ossxp-com/"name="github"/> 
<default remote="github" revision="refs/heads/test-0.1"/> 
<project name="testi"path="test/test1"> 

<copyfile dest="Makefile"src="root.mk"/> 

</project> 

<project name="test2" path="test/test2"/> 

</manifest> 


仔细 看 看 上 面 的 清单 文件 ， 可 以 注意 到 默认 的 版 本 指 辐 到 了 
refs/heads/test-0.13| 用 所 指 癌 的 分 支 test-0.1。 


如 果 在 子 项 目 中 修改 、 提 交 ， 然 后 使 用 repo push 会 将 改动 推送 到 
远程 版 本 库 的 test-0.1 分 文中 。 


8. 切 换 到 清单 库 里 程 碑 版 本 
执行 如 下 命令 可 以 查看 清单 库 包 含 的 里 程 碑 版 本 : 


$git ls-remote--tags git://github.com/ossxp-com/manifest.git 
43e5783a58b46e97270785aa967f09046734c6ab refs/tags/current 
3a6a6da36840e716a14d52252e7b40e6ba6cbdea refs/tags/current^{} 
4735d32613eb50a6c3472cc8087ebf79cc46e0cg0 refs/tags/v0O.1 
fb1a1b7302a893092ce8b356e83170eee5863f43 refs/tags/v0O.1^{} 
b23884d9964660c8dd34b343151aaf968a744400 refs/tags/v0.1.1 
9c4c287069e29d21502472acac34f28896d7b5cc refs/tags/v0.1.1^{} 
127d9789cd4312ed279a7fa683c43eec73d2b28b refs/tags/v0.1.2 
47aaa83866f6d910a118a9a19c2ac3a2a5819b3e refs/tags/v0.1.2^{} 
af3abb7edoa9gef7063e9d814510c527287c92ef6 refs/tags/v0O.1.3 
1 


99c69bcfd7e2e7737cc62a7d95f39c6b9ffaf31a refs/tags/v0.1.3^{} 


可 以 从 任意 里 程 碑 版 本 的 清单 库 初始 化 整个 项 目 。 


$mkdir vO.1.2 

$cd vO.1.2 

$repo init-u git://github.com/ossxp-com/manifest.git-b 
refs/tags/vO.1.2 

$repo sync 


当 子 项 目 代 码 全 部 同步 完成 后 执行 make 命 令 。 可 以 看 到 各 个 子 项 
目的 版 本 及 清单 库 的 版 本 不 同 于 之 前 的 输出 。 


$make 

Version of test1:1:0.1.2 

Version of test2:2:0.1.2 
0.1. 


Version of manifest:v 2 


第 26 章 ”Git 和 和 SVN 协同 模型 


在 本 篇 的 最 后 ， 将 会 从 另外 一 个 角度 来 看 版 本 库 协 同 。 不 是 不 同 
的 用 户 在 使 用 Git 版 本 库 时 如 何 协 同 ， 也 不 是 一 个 项 目 包 含 多 个 Git 版 
本 库 时 如 何 协同 ， 而 是 当 版 本 控制 系统 不 是 Git (如 Subversion) 时 ， 
如 何 能 够 继续 以 Git 的 方式 进行 操作 。 


Subversion 会 在 商业 软件 开发 中 占有 一 席 之 地 ， 因 为 依然 会 有 公司 
需要 严格 而 复杂 的 源 代码 授权 。 对 于 熟悉 了 Git 的 用 户 ， 一 定 会 对 
Subversion 的 那 种 一 旦 脱离 网 络 和 服务 器 便 寸 步 难 行 的 工作 模式 厌烦 透 
顶 。 实 际 上 对 Subversion 的 集中 式 版 本 控制 的 不 满 和 改进 在 Git 延 生 之 


前 就 发 生 了 ， 这 就 是 SVK 01 。 


在 2003 年 〈Git 诞 生 的 前 两 年 ) ， 台 湾 的 高 嘉 良 就 开发 了 SVK， 用 
分 布 式 版 本 控制 的 方法 操作 SVN。 其 设计 思想 非常 朴素 ， 既 然 SVN 的 
用 户 可 以 看 到 有 访问 权限 数据 的 全 部 历史 ， 那 么 也 应 该 能 够 依据 历史 
重建 一 个 本 地 的 SVN 版 本 库 ， 这 样 很 多 SVN 操 作 都 可 以 通过 本 地 的 
SVN 进 行 ， 从 而 脱离 网 络 。 当 对 本 地 版 本 库 的 修改 感到 满意 后 ， 通 过 
本 地 SVN 版 本 和 服务 器 SVN 版 本 库 之 间 的 双向 同步 ， 将 改动 归并 到 服 
务 器 上 “。 这 种 工作 方式 真 的 非常 酷 。 


不 必 为 SVK 的 文档 缺乏 及 不 再 维护 而 感到 居 惜 ， 因 为 有 更 强 的 工 
具 登 场 了 ， 这 就 是 git-svn。git-swn 是 Git 软 件 包 的 一 部 分 ， 用 Perl 语 言 开 


发 。 它 的 工作 原理 是 : 


将 Subversion 版 本 库 在 本 地 转换 为 一 个 Git 库 。 


转换 可 以 基于 Subversion 的 某 个 日 隶 ， 或 者 基于 某 个 分 支 ， 或 者 整 
个 Subversion 代 码 库 的 所 有 分 文 和 里 程 碑 。 


远程 的 Subversion 版 本 库 可 以 和 本 地 的 Git 双 同 同步 。Git 本 地 库 修 
改 推送 到 远程 Subversion 有 版 本 库 ， 反 之 亦 然 。 


git-svn 作 为 Git 软 件 包 的 一 部 分 ， 当 Git 从 源码 包 进 行 安 装 时 会 默认 
安装 ， 提 供 git svn 命 令 。 而 几乎 所 有 的 Linux 发 行 版 都 将 git-svn 作 为 一 
个 独立 的 软件 单独 发 布 ， 因 此 需要 单独 安装 。 例 如 Debian 和 Ubuntu 运 


行 下 面 的 命令 安装 git-svn。 
$sudo aptitude install git-svn 


将 git-svn 独 立 安 装 是 因为 git-svn 软 件 包 有 着 特殊 的 依赖 ， 即 依赖 


i 


Subversion 的 Perl 语 言 绑 定 接 口 ，Debian/Ubuntu 上 由 libsvn-perl 软 件 包 


提供 。 


当 git-svn 正 确 安 闭 后， 就 可 以 使 用 git svn 命 令 了 。 但 如 果 在 执行 git 
sSVn--version 时 遇 到 下 面 的 错误 ， 则 说 明 Subversion 的 Per 语言 绑 定 没有 


正确 安装 。 


$git svn--version 

Can't locate loadable object for module SVN:_Core in@INC(@INC 
contains: 

/usr/share/perl1/5.10.1/etc/perl/usr/local/lib/per1l/5.10.1 

/usr/local/share/per1/5.10.1/usr/lib/perl5/usr/share/perl5 

/usr/lib/per1l/5.10/usr/share/per1l/5.10/usr/local/lib/site perl 

/usr/local/lib/per1l/5.10.0/usr/local/share/perl1/5.10.0. )at 

/usr/lib/perl5/SVN/Base.pm line 59 

BEGIN failed--compilation aborted at/usr/lib/perl5/SVN/Core.pm 
line 5. 

Compilation failed in require at/usr/lib/git-core/git-svn line 
41， 


遇 到 上 面 的 情况 ， 需 要 检查 本 机 是 否 正确 安装 了 Subversion 及 


Subversion 的 Perl 语 言 绪 定 。 


为 了 便于 对 git-svn 的 介绍 和 演示 ， 要 有 一 个 Subversion 版 本 库 ， 并 
且 要 有 提交 权限 以 便 演 示 如 何 用 Git| 可 Subversion 进 行 提 交 。 下 面 就 在 
本 地 创建 一 个 Subversion 版 本 库 。 


$svnadmin create/path/to/svn/repos/demo 
$svn co file:///path/to/svn/repos/demo svndemo 
取出 版 本 0 

$cd svndemo 

$mkdir trunk tags branches 

$svn add* 

A branches 

A tags 

A trunk 

$svn ci-m "initialized." 

增加 branches 


增加 tags 
增加 trunk 
提交 后 的 版 本 为 1 。 


再 癌 Subversion 开 发 主线 trunk 中 添加 些 数据 。 


$echo hello>trunk/README 
$svn add trunk/README 

A trunk/README 

$svn ci-m "hello" 

增加 trunk/README 

传输 文件 数据 ， 
提交 后 的 版 本 为 2。 


建立 分 文 : 


s svn up 
$$ svn cp trunk branches/demo-1.0 
五 zamchesy/ydGemo-1.f 


; svn ci ~m "new branch: demo~-~1.0" 
复 加 branches/demo-1.0 


提交 后 的 版 本 为 3 
建 站 里 程 碑 
S svn cp -m "new tag: vl.0" trunk file:///path/to/svn/repos/demo/tags/vl1.0 


次 交 后 的 版 认为 4 


26.1 使 用 gitrsvn 的 一 般 流 程 


使 用 git-svn 的 一 般 流程 参见 图 26-1 


tt 


让 


图 26-1 git-svn 工作 流 


首先 用 git svn clone 命令 对 Subversion 进行 克隆， 创建 一 个 包含 git-svn 扩展 的 
本 地 Git 库 。 在 下 面 的 示例 中 ， 使 用 Subversion 的 本 地 协议 (file:/) 来 访问 之 前 创立 的 
Subversion 示例 版 本 库 ， 实 际 上 git-svn 可 以 使 用 任何 Subversion 可 用 的 协议 ， 并 可 以 对 远 
程 版 本 库 进行 操作 。 


$ git svn clone -s file:///path/to/svn/repos/demo git-svn-demo 
Initialized empty Git repository in /path/to/my/workspace/qit-svn-demo/ .9it/ 
rl = 2c73d657dfc3alceca9d465b0b98E9e1l23b92bb4 lrefs/remotes/trunk) 

入 README 
r2 = 1863f91b45defl59a3ed2c4c4c9428c25213£956 [refs/remotes/trunk) 
Found possible branch point: file:///path/to/svn/repos/demo/trunk => 
file:///path/to/svn/repos/demo/branches/demo-1.0, 2 
Found branch parent: (refs/remotes,/demo-1.0]} 
1863f9ibaSdefiS9a3ed2c4c4c9428c25213f956 
Following parent with do switch 


Successfully followed parent 

r3=1adcd5526976fe2a796d932ff92d6c41b7eedcc4(refs/remotes/demo- 
1.0) 

Found possible branch 
point:file:///path/to/svn/repos/demo/trunk=> 

file:///path/to/svn/repos/demo/tags/v1.0,2 

Found branch parent:(refs/remotes/tags/v1.0) 

1863f91b45def159a3ed2c4c4c9428c25213f956 

Following parent with do_switch 

Successfully followed parent 

r4=c1i2aa40c494b495a846e73ab5a3c787calad81e9(refs/remotes/tags/vi1 
.0) 

Checked out HEAD: 

file:///path/to/svn/repos/demo/trunk r2 


从 上 面 的 输出 可 以 看 出 ， 当 执行 了 git svn clone 之 后 ， 在 本 地 工作 
目录 创建 了 一 个 Git 库 〈gitrsvn-demo) ， 并 将 Subversion 的 每 一 个 提交 
都 转换 为 Git 库 中 的 提交 。 进 入 git-svn-demo 目 录 ， 看 看 用 git-svn 克 隆 出 
来 的 版 本 库 。 


$cd git-svn-demo/ 

$git branch-a 

*master 

remotes/demo-1.0 

remotes/tags/vi1.0 

remotes/trunk 

$git log 

commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:49:41 2010+0000 

hello 

git-svn-id:file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 2c73d657dfc3aliceca9d465b0b98f9e123b92bb4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:47:03 2010+0000 

initialized. 

git-svn-id:file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


看 到 Subversion 版 本 库 的 分 支 和 里 程 碑 都 被 克隆 出 来 ， 并 保存 在 
refs/remotes 下 的 引用 中 。 在 git log 的 输出 中 ， 可 以 看 到 Subversion 的 提 
交 的 确 被 转换 为 Git 的 提交 。 


下 面 就 可 以 在 Git 库 中 进行 修改 ， 并 在 本 地 提交 (用 git commit 命 


和 ) 。 


$cat README 
hello 


$echo "I am fne."> >README 

$git add-u 

$git commit-m "my hack 1." 

[master 55e5fd7]my hack 1. 

1 files changed,1 insertions(+),0 deletions(-) 
$echo "Thank you."> >README 

$git add-u 

$git commit-m "my hack 2." 

[master fle00b5]my hack 2. 

1 files changed,1 insertions(+),0 deletions(-) 


对 工作 区 中 的 README 文 件 修改 了 两 次 ， 并 进行 了 本 地 的 提交 。 


查看 这 时 的 提交 日 志 ， 会 发 现 最 新 的 两 个 提交 和 之 前 的 历次 提交 上 略 有 
不 同 ， 最 新 的 两 个 提交 的 提交 说 明 中 不 包含 git-svn-id: 标 记 。 


$git log 

commit fle00b52209f6522dd8135d27e86370de552a7b6 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Nov 4 15:05:47 2010+0800 

my hack 2. 

commit 55e5fd794e6208703aa999004ec2e422b3673ade 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Nov 4 15:05:32 2010+0800 

my hack 1. 

commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:49:41 2010+0000 

hello 
git-svn-id:file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 2c73d657dfc3aliceca9d465b0b98f9e123b92bb4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:47:03 2010+0000 

initialized. 
git-svn-id:file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


现在 就 可 以 向 Subversion 服 务 恬 推送 改动 了 。 但 在 真实 的 环境 中 ， 
往往 在 癌 服 务 器 推送 上 时， 已经 有 其 他 用 户 在 服务 器 上 进行 了 提交 ， 而 


且 更 糟 的 是 ， 先 于 我 们 的 提交 会 造成 我 们 的 提交 冲突 ! 现在 就 人 为 地 
制造 一 个 冲突 ， 使 用 syn 命令 在 Subversion 版 本 库 中 执行 一 次 提交 。 


$svn checkout file:///path/to/svn/repos/demo/trunk demo 
A demo/README 

取出 版 本 4。 

$cd demo/ 

$cat README 

hello 

$echo "HELLO."> README 

$svn commit-m "hello->HELLO." 

正在 发 送 README 

传输 文件 数据 ， 
提交 后 的 版 本 为 5 。 


好 的 ， 已 经 模拟 了 一 个 用 户 先 于 我 们 更 改 了 Subversion 版 本 库 。 现 
在 回 到 用 git-svn 克 隆 的 本 地 版 本 库 ， 执 行 git svn dcommit 操 作 ， 将 Git 
中 的 提交 推送 到 Subversion 版 本 库 中 。 


$git svn dcommit 

Committing to file:///path/to/svn/repos/demo/trunk... 
事务 过 时 :文件 "/trunk/README" 已 经 过 时 at/usr/lib/git-core/git-svn 
line 572 


显然 ， 由 于 Subversion 版 本 库 中 包含 了 新 的 提交 ， 导 致 执行 git svn 
dcommit 出 错 。 这 时 须 执行 git svn fetch 命 令 ， 以 从 Subversion 版 本 库 获 
取 更 新 。 


$git svn fetch 

M README 
r5=fae6dab863ed2152f71bcb2348d476d47194fdd4(refs/remotes/trunk) 
$git status 

#0n branch master 


nothing to commit(working directory clean) 


当 获 取 了 新 的 Subversion 提 区 之 后 ， 需 要 执行 git svn rebase 将 Git 中 
未 推送 到 Subversion 的 提交 通过 变 基 操作 转化 为 继 Subversion 最 新 提交 
的 线性 提交 。 这 是 因为 Subversion 的 提交 都 是 线性 的 。 


$git svnrebase 

First,rewinding head to replay your work on top of it... 

Applying:my hack 1. 

Using index info to reconstruct a base tree... 

Falling back to patching base and 3-way merge... 

Auto-merging README 

CONFLICT(content):Merge conflict in README 

Failed to merge in the changes. 

Patch failed at 0001 my hack 1. 

When you have resolved this problem run "git rebase--continue". 

If you would prefer to Skip this patch,instead run "git rebase-- 
skip". 

To restore the original branch and stop rebasing run "git 
rebase--abort". 

rebase refs/remotes/trunk:command returned error:1 


果不其然 ， 变 基 时 发 生 了 冲突 ， 这 是 因为 Subversion 中 他 人 的 修改 
和 我 们 在 Git 库 中 的 修改 都 改动 了 同一 个 文件 ， 并 且 改 动 了 相近 的 行 。 
下 面 按照 git rebase 冲 突 解 决 的 标准 步 又 进行 ， 直 到 成 功 完成 灾 基 操 
作 ， 具 体操 作 步 又 如 下 。 


(1) 先 编 辑 README 文 件 以 解决 冲突 。 


$git status 

#Not currently on any branch. 

#Unmerged paths: 

#(USe "git reset HEAD<file>..." to unstage) 

#(USe "git add/rm<file>..." as appropriate to mark resolution) 


# 

#both modified:README 

# 

no changes added to commit(use "git add" and/or "git commit-a") 
$vi README 


(2) 处 于 冲突 状态 的 REAEME 文 件 的 内 容 。 


<<<<<<<HEAD 
HELLO. 


I am fine. 
>>>>>>>my hack 1. 


(3) 下 面 是 修改 后 的 内 容 ， 保 存 退出 。 


HELLO. 
I am fine. 


(4) 执行 git add 命 令 解决 冲突 。 
$git add README 


(5) 调用 git rebase--continue 完 成 变 基 操作 。 


$git rebase--continue 

Applying:my hack 1. 

Applying:my hack 2. 

Using index info to reconstruct a base tree... 
Falling back to patching base and 3-way merge... 
Auto-merging README 


(6) 看 看 变 基 之 后 的 Git 版 本 库 日 志 : 


$git 1og 

commit e382f2e99eca07bc3a92ece89f80a7a5457acfd8 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Nov 4 15:05:47 2010+0800 

my hack 2. 

commit 6e7eOc7dccf5a072404a28f0O6ce0c83d77988b0b 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Nov 4 15:05:32 2010+0800 

my hack 1. 

commit fae6dab863ed2152f71bcb2348d476d47194fdd4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Thu Nov 4 07:15:58 2010+0000 

hello->HELLO. 
git-svn-id:file:///path/to/svn/repos/demo/trunk@s5 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:49:41 2010+0000 

hello 

git-svn-id:file:///path/to/svn/repos/demo/trunk@2 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 2c73d657dfc3aliceca9d465b0b98f9e123b92bb4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:47:03 2010+0000 

initialized., 

git-svn-id:file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


(7) 当 变 基 操 作成 功 完成 后 ， 再 执行 git svn dcommit 向 Subversion 
推送 Git 库 中 的 两 个 新 提交 。 


$git svndcommit 

Committing to file:///path/to/svn/repos/demo/trunk... 

M README 

Committed r6 

M README 
r6=d0eb86bdfad4720e0a24edc49ec2b52e50473e83(refs/remotes/trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 


Unstaged changes after reset : 

M README 

M README 

Committed r7 

M README 
r7=69f4aa56eb96230aedd7c643f65d03b618ccc9e5(refs/remotes/trunk) 
No changes between current HEAD and refs/remotes/trunk 
Resetting to the latest refs/remotes/trunk 


(8) 推送 之 后 本 地 Git 库 中 最 新 的 两 个 提交 的 提交 说 明 中 也 岁入 
了 git-svn-id: 标 签 。 这 个 标签 的 作用 非常 重要 ， 在 下 一 会 子 以 介绍 。 


$git 10g-2 

commit 69f4aa56eb96230aedd7c643f65d03b618ccc9e5 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2> 
Date:Thu Nov 4 07:56:38 2010+0000 

my hack 2. 

git-svn-id:file:///path/to/svn/repos/demo/trunk@7 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit doeb86bdfad4720e0a24edc49ec2b52e50473e83 

Author:jiang xin<jiang xin@f79726c4-f016-41bd-acd5-6c9acb7664b2 


Date:Thu Nov 4 07:56:37 2010+0000 

my hack 1. 
git-svn-id:file:///path/to/svn/repos/demo/trunk@6 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


[1| http://svk.bestpractical.com/ 


26.2 gitrsvn 的 奥秘 
通过 上 面 对 git-svn 的 工作 流程 的 介绍 ， 相 信 您 已 经 能 够 体会 到 git- 
svn 的 强大 。 那 么 git-svn 是 怎么 做 到 的 呢 ? 


git-svn 只 是 在 本 地 Git 库 中 增加 了 一 些 附加 的 设置 和 特殊 的 引用 ， 
并 引入 了 附加 的 可 重建 的 数据 库 实现 对 Subversion 版 本 库 的 跟踪 。 


26.2.1 Git 库 配 置 文 件 的 扩展 及 分 支 映 射 


当 执 行 git svn init 或 git svn clone 时 ，git-svn 会 通过 在 Git 库 的 配置 文 
件 中 增加 一 个 小 节 ， 记 录 Subversion 版 本 库 的 UREL， 以 及 Subversion 分 
文 /里 程 碑 和 本 地 Git 库 的 引用 之 间 的 对 应 关系。 


例如 : 当 执行 git svn clone-s file:///path/to/svn/repos/demo 指 令 时 ， 
会 在 创建 的 本 地 Git 库 的 配置 文件 .git/config 中 引入 下 面 的 新 配置 : 
[svn-remote "svn"] 
url=file:///path/to/svn/repos/demo 
fetch=trunk:refs/remotes/trunk 


branches=branches/*:refs/remotes/* 
tags=tags/*:refs/remotes/tags/* 


默认 svn-remote 的 名 字 为 sn， 所 以 新 增 的 配置 小 节 的 名 字 为 : 
[svn-remote "svn"]。 在 git-svn 克 隆 上 时， 可 以 使 用 --remote 参 数 设 置 不 同 


的 svn-remote 名 称 ， 但 是 并 不 建议 使 用 。 因 为 一 旦 使 用 --remote 人 参数 更 
改 svn-remote 名 称 ， 必 须 在 git-svn 的 其 他 命令 中 都 使 用 --remote 参 数 ， 
否则 报告 [svn-remote "svn"] 配 置 小 节 未 找到 。 


该 小 节 中 主要 的 配置 有 : 

url=<URL> 

设置 Subversion 版 本 库 的 地 址 。 

fetch=< svn-path>: <<git-refspec> 
Subversion 的 开发 主线 和 Git 版 本 库 引 用 的 对 应 关系 。 


在 上 例 中 Subversion 的 trunk 目 孙 对 应 于 Git 的 refs/remotes/trunk 引 


branches= < svn-path>: < git-refspec> 


Subversion 的 开发 分 文 和 Git 版 本 库 引 用 的 对 应 关系 。 可 以 包含 多 
条 branches 的 设置 ， 以 便 将 分 散在 不 同 目 录 下 的 分 支 汇总 。 


在 上 例 中 Subversion 的 branches 子 目 孙 的 下 一 级 子 目 孙 
(branches/*) 所 代表 的 分 支 在 Git 的 refs/remotes/ 下 建立 引用 。 


tags=< svn-path>: < git-refspec> 


Subversion 的 里 程 碑 和 Git 版 本 库 引 用 的 对 应 关系 ， 可 以 包含 多 条 
tags 的 设置 ， 以 便 将 分 散在 不 同 目 永 下 的 里 程 碑 汇 总 。 


在 上 例 中 Subversion 的 tags 子 目录 的 下 一 级 子 目 录 (tags/*) 所 代表 
的 里 程 碑 在 Git 的 refs/remotes/tags 下 建立 引用 。 


可 以 看 到 Subversion 的 主线 和 分 支 默 认 都 直接 被 映射 到 
refs/remotes/ 下 。 如 trunk 主 线 对 应 于 refs/remotes/trunk， 分 文 demo-1.0 对 
应 于 refs/remotes/demo-1.0。Subversion 的 里 程 原因 为 有 可 能 和 分 支 同 
名 ， 因 此 被 映射 到 refs/remotes/tags/ 之 下 ， 这 样 里 程 碑 和 分 支 的 映射 就 
放 到 了 不 同 的 目录 下 ， 不 会 互相 影响 。 


26.2.2 ”Git 工 作 分 支 和 Subversion 如 何 对 应 


Git 默 认 的 工作 分 支 是 master， 而 看 到 上 例 中 的 Subversion 主 线 在 
Git 中 对 应 的 远程 分 支 为 refs/remotes/trunk。 那 么 在 执行 git svn rebase 
时 ，git-svn 是 如 何 知道 当前 的 HEAD 对 应 的 分 支 是 基于 哪个 Subversion 
跟 踩 分 文 进行 的 变 基 呢 ? 还 有 就 是 执行 git svn dcommit 时 ， 当 前 的 工作 
分 文 应 该 将 改动 推送 到 哪个 Subversion 分 文中 去 呢 ? 


很 目 然 地 会 按照 Git 的 方式 进行 思考 ， 期 望 在 .git/config 配 置 文件 中 
找到 类 似 [branch master] 之 类 的 配置 小 节 。 实 际 上 ， 在 git-svn 的 Git 库 的 
配置 文件 中 可 能 根本 就 不 存在 [branch..…….] 小 节 。 那 么 gitrsvn 是 如 何 确 
定 当 前 Git 工 作 分 支 和 远程 Subversion 版 本 库 的 分 支 建立 了 对 应 呢 ? 


其 实 奥 秘 束 在 Git 的 日 志 中 。 当 在 工作 区 执行 git log 时 ， 会 看 到 包 
合 git-svn-id: 标 识 的 特殊 日 志 。 发 现 的 最 近 的 一 个 git-svn-id: 标 识 会 确定 


当前 分 文 提 交 的 Subversion 分 文 。 


下 面 继续 上 一 廊 的 示例 ， 先 切换 到 分 支 ， 并 将 提交 推送 到 
Subversion 的 分 支 demo-1.0 中 ， 具 体操 作 过程 如 下 。 


(1) 首先 在 Git 库 中 会 看 到 有 一 个 对 应 于 Subversion 分 支 的 远程 分 
文 和 一 个 对 应 于 Subversion 里程 夏 的 远程 引用 。 


$git branch-r 
demo-1.0 
tags/vi.0 
trunk 


(2) 然后 基于 远程 分 支 demo-1.0 建 立 本 地 工作 分 支 myhack。 


$git checkout-b myhack refs/remotes/demo-1.0 
Switched to a new branch'myhack'" 

$git branch 

master 

*myhack 


(3) 在 myhack 分 支 做 一 些 改动 并 提交 。 


$echo "Git"> >README 

$git add-u 

$git commit-m "say hello to Git." 

[myhack d391fd7]say hello to Git. 

1 files changed,1 insertions(+),0 deletions(-) 


(4) 下 面 看 看 Git 的 提交 日 志 。 


$git 1og--frst-parent 

commit d391fd75c33f62307c3add1498987fa3eb70238e 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Fri Nov 5 09:40:21 2010+0800 

say hello to Git. 

commit 1adcd5526976fe2a796d932ff92d6c41b7eedcc4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:54:19 2010+0000 

new branch:demo-1.0 
git-svn-id:file:///path/to/svn/repos/demo/branches/demo-1.0Q3 
f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 1863f91b45def159a3ed2c4c4c9428c25213f956 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:49:41 2010+0000 

hello 

git-svn-id:file:///path/to/svn/repos/demo/trunk@2 


f79726c4-f016-41bd-acd5-6c9acb7664b2 

commit 2c73d657dfc3aliceca9d465b0b98f9e123b92bb4 
Author:jiangxin<jiangxin@f79726c4-f016-41bd-acd5-6c9acb7664b2>> 
Date:Mon Nov 1 05:47:03 2010+0000 

initialized. 

git-svn-id:file:///path/to/svn/repos/demo/trunk@1 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


(5) 看 到 了 上 述 Git 日 志 中 出 现 的 第 一 个 git-svn-id: 标 识 的 内 容 


git-svn-id:file:///path/to/svn/repos/demo/branches/demo-1.0Q3 
f79726c4-f016-41bd-acd5-6c9acb7664b2 


这 残 是 说 ， 当 需要 将 Git 提 区 推送 给 Subversion 服 务 器 时 ， 需 要 推 
送 到 地 址 : fie:/Wpathyto/svn/repos/demo/branches/demo-1.0。 


(6) 执行 git svn dcommit， 果 然 是 推送 到 Subversion 的 demo-1.0 分 
支 o 


$git svn dcommit 

Committing to file:///path/to/svn/repos/demo/branches/demo- 
ss 

M README 

Committed r8 

M README 

r8=a8b32d1b533d308bef59101c1if2c9ai6baf91e48(refs/remotes/demo- 
1.0) 

No changes between current HEAD and refs/remotes/demo-1.0 

Resetting to the latest refs/remotes/demo-1.0 


26.2.3 ”其 他 辅助 文件 


在 Git 版 本 库 中 ，git-svn 在 .giysvn 目 录 下 保存 了 一 些 索 引文 件 , 便 


于 git-svn 更 加 快速 地 执行 。 
.git/svn/.metadata 文 件 是 类 似 于 .git/config 文 件 一 样 的 INIX 件 ， 其 


中 保存 了 版 本 库 的 URL、 版 本 库 UUID、 分 文 和 里 程 碑 的 最 后 获取 的 版 


本 号 等 。 


;This file is used internally by git-svn 
;You should not have to edit it 
[svn-remote "svn"] 
reposRoot=file:///path/to/svn/repos/demo 
uuid=f79726c4-f016-41bd-acd5-6c9acb7664b2 


branches-maxRev=8 
tags -maxRev=8 


在 .git/svn/refs/remotes 目 录 下 ， 以 各 个 分 支 和 里 程 碑 为 名 的 各 个 子 
目录 下 都 包含 了 一 个 名 为 .rev_map.<SVN-UUID > 的 索引 文件 ， 这 个 
文件 用 于 记录 Subversion 的 提交 ID 和 Git 的 提交 ID 的 映射 。 

目录 .git/svn 的 辅助 文件 由 git-svn 维 护 ， 不 要 手工 修改 否则 会 造成 


git-svn 不 能 正常 工作 。 


26.3 ”多样 的 git-svn 殉 隆 模 式 


在 前 面 的 git-svn 示 例 中 ， 使 用 git svn clone 命 令 完成 对 远程 版 本 库 
的 克隆 ， 实 际 上 git svn clone 相 当 于 两 条 命令 ， 即 : 


git svn clone=git svn init+git svn fetch 


命令 git svn init 只 完成 两 个 工作 。 一 是 在 本 地 建立 一 个 空 的 Git 版 
本 库 ， 另 外 是 修改 .gitconfig 文 件 ， 在 其 中 建立 Subversion 和 Git 之 间 的 
分 支 映 射 关系 。 在 实际 使 用 中 ， 我 更 喜欢 使 用 git svn init 命 令 ， 因 为 这 
样 可 以 对 Subversion 和 Git 的 分 文 映 射 进行 手工 修改 。 该 命令 的 用 法 


三 | 
AE: 


法 :git svn init[options]<subversion-url> [local-dir] 
可 选 的 主要 参数 有 : 
--Stdlayout,，-S 
--trunk,-T<arg> 
--branches, - -b=s@ 
--tags, --t=s@ 
--config-dir<arg> 
--ignore-paths<arg> 
--prefix<arg> 
--USername<arg> 


其 中 --username 参 数 用 于 设 定 远程 Subversion 服 务 器 认证 时 提供 的 
用 户 名 。 参 数 --prefix 用 于 设置 在 Git 的 refs/remotes 下 保存 引用 时 使 用 的 


前 级 。 参 数 --ignore-paths 后 面 跟 一 个 正则 表达 式 定 义 忽 略 的 文件 列 
表 ， 这 些 文件 将 不 予 克 隆 。 


最 常用 的 参数 是 -s。 该 参数 和 前 面 演示 的 git clone 命 令 中 的 一 样 ， 
即使 用 标准 的 分 文 /里 程 碑 部 署 方式 克隆 Subversion 版 本 库 。Subversion 
约定 俗 成 使 用 trunk 目 录 跟 躁 主线 的 开发 ， 使 用 branches 目 录 体 存 各 个 
分 文 ， 使 用 tags 目 录 来 记录 里 程 碑 。 


即 命令 


$git svn init-s file:///path/to/svn/repos/demo 


和 下 面 的 命令 等 效 : 


$git svn init-T trunk-b branches-t tags 
file:///path/to/svn/repos/demo 


有 的 Subversion 版 本 库 的 分 文 可 能 分 散 于 不 同 的 目 了 永 下 ， 例 如 有 的 
位 于 branches 目 录 ， 有 的 位 于 sandbox 目 录 ， 可 以 使 用 下 面 的 命令 : 


$git svn init-T trunk-b branches-b sandbox-t tags 
file:///path/to/svn/repos/demo git-svn-test 
Initialized empty Git repository in/path/to/my/workspace/git- 


svn-test/.git/ 


查看 本 地 克隆 版 本 库 的 配置 文件 : 


$cat git-svn-test/.git/config 


[core] 

repositoryformatversion=0 
filemode=true 

bare=false 

logallrefupdates=true 

[svn-remote "svn" 
url=file:///path/to/svn/repos/demo 
fetch=trunk:refs/remotes/trunk 
branches=branches/*:refs/remotes/* 
branches=sandbox/*:refs/remotes/* 
tags=tags/*:refs/remotes/tags/* 


可 以 看 到 在 [svn-remote "svn"] 小 广 中 包含 了 两 条 branches 配 置 ， 
就 会 实现 将 Subversion 分 散 于 不 同 目录 的 分 支 都 克隆 出 来 。 如 果 担 心 
Subversion 的 branches 目 录 和 sandbox 目 录 下 出 现 同名 的 分 文 ， 从 而 导致 
在 Git 库 的 refsremotes/ 下 造成 覆盖 ， 可 以 在 版 本 库 尚 未 执行 git svn fetch 
之 前 编辑 .giVyconfig 文 件 ， 避 免 可 能 出 现 的 覆盖 。 例 如 编辑 后 的 [svn- 


remote "Svn"] 配 置 小 节 : 


[svn-remote "svn" 
url=file:///path/to/svn/repos/demo 
fetch=trunk:refs/remotes/trunk 
branches=branches/*:refs/remotes/branches/* 
branches=sandbox/*:refs/remotes/sandbox/* 
tags=tags/*:refs/remotes/tags/* 


如 果 项 目的 分 支 或 里 程 碑 非 常 多 ， 也 可 以 修改 [svn-remote "svn"] 
配置 小 节 中 的 版 本 号 通配符 ， 使 得 只 获取 部 分 分 支 或 里 程 碑 。 例 如 下 
面 的 配置 小 节 : 

[svn-remote "svn" 


url=http://server.org/svn 
fetch=trunk/src:refs/remotes/trunk 


branches=branches/{red, green}/src:refs/remotes/branches/* 
tags=tags/{1.0,2.0}/src:refs/remotes/tags/* 


如 果 只 关心 Subversion 的 某 个 分 支 甚至 某 个 子 日 隶 ， 而 不 关心 其 他 
分 支 或 日 录 ， 那 束 更 简单 了 ， 不 市 参数 地 执行 git svn init 针 对 
Subversion 的 某 个 具体 路 径 执 行 初 始 化 就 可 以 了 。 


$git svn init file:///path/to/svn/repos/demo/trunk 


有 的 情况 下 ， 版 本 库 太 大 ， 而 且 对 历史 不 感 兴趣 ， 可 以 只 克隆 最 
近 的 部 分 提交 。 这 时 可 以 通过 git svn fetch 命 令 的 -了 参数 实现 部 分 提 区 
的 区 隆 。 


$git svn init file:///path/to/svn/repos/demo/trunk git-svn-test 

Initialized empty Git repository in/path/to/my/workspace/git- 
svn-test/.git/ 

$cd git-svn-test 

$git svn fetch-r 6:HEAD 


A README 

r6=053b641b7edd2f1ia59a007f27862d98fe5bcda57 (refs/remotes/git- 
svn) 

M README 

r7=75c1i7ea61d8527334855a51le65ac98c981f545d7 (refs/remotes/git- 
svn) 


Checked out HEAD: 
file:///path/to/svn/repos/demo/trunk r7 


当然 也 可 以 使 用 git svn clone 命 令 实现 部 分 克隆 : 


$git svn clone-r 6:HEAD\ 

file:///path/to/svn/repos/demo/trunk git-svn-test 

Initialized empty Git repository in/path/to/my/workspace/git- 
svn-test/.git/ 

A README 


r6=053b641b7edd2f1ia59a007f27862d98feS5bcda57 (refs/remotes/git- 


svn) 

M README 

r7=75c1i7ea61d8527334855a51le65ac98c981f545d7 (refs/remotes/git- 
svn) 


Checked out HEAD: 
file:///path/to/svn/repos/demo/trunk r7 


26.4 共享 git-svn 的 克隆 库 


当 一 个 Subversion 版 本 库 非 常 庞 大 而 且 还 不 在 同一 个 局 域 网 内 ， 执 
行 git svn clone 可 能 需要 人 花费 很 多 时 间 。 为 了 避免 因 重 复 执 行 git svn 
clone 而 导致 时 间 上 的 浪费 ， 可 以 将 一 个 已 经 使 用 git-svn 克 隆 出 来 的 Git 
库 共 译 ， 其 他 人 基于 此 Git 进 行 殉 隆 ， 然 后 再 用 特殊 的 方法 重建 和 
Subversion 的 关联 。 还 记得 之 前 提 人 到 过 .git/svn 目 录 下 的 辅助 文件 可 以 重 
建 吗 ? 


例如 通过 工作 区 中 已 经 存在 的 git-svn-demo 执 行 克 隆 。 


$git clone git-svn-demo myclone 
Initialized empty Git repository 
in/path/to/my/workspace/myclone/ .git/ 


进入 狐 的 克隆 中 ， 会 发 现 狐 的 克隆 缺乏 跟踪 Subversion 分 支 的 引 


用 ， 即 refs/remotes/trunk 等 。 


$cd myclone/ 

$git branch-a 

*master 

remotes/origin/HEAD- >origin/master 
remotes/origin/master 
remotes/origin/myhack 


这 是 因为 Git 克 隆 默认 不 复制 远程 版 本 库 的 refsremotes/ 下 的 引用 。 
可 以 用 git fetch 命 令 获取 refs/remotes 的 3 引用。 


$git fetch origin refs/remotes/*:refs/remotes/* 
From/path/to/my/workspace/git-svn-demo 

*[new branch]demo-1.0->demo-1.0 

*[new branch]tags/v1.0-~>tags/vi.0 

*[new branch]trunk->trunk 


现在 这 个 从 git-svn 库 中 克隆 出 来 的 版 本 库 已 经 有 了 相同 的 
Subversion 跟 踩 分 文 ， 但 是 .giyconfig 文 件 还 缺乏 相应 的 [Svn-remote 
"svn"] 配 置 。 可 以 通过 使 用 同样 的 git svn init 命 令 实现 。 


$pwd 

/path/to/my/workspace/myclone 

$git svn init-s file:///path/to/svn/repos/demo 
$git config--get-regexp 'svn-remote.*' 
svn-remote.svn.url file:///path/to/svn/repos/demo 
svn-remote.svn.fetch trunk:refs/remotes/trunk 
svn-remote.svn.branches branches/*:refs/remotes/* 
svn-remote.svn.tags tags/*:refs/remotes/tags/* 


但 是 克隆 版 本 库 相 比 用 git-svn 克 隆 的 版 本 库 还 缺乏 .giysvn 下 的 辅 
助 文 件 。 实 际 上 可 以 用 git svn rebase 命 令 重 建 ， 同 时 这 条 命令 也 可 以 变 
基 到 Subversion 相 应 分 支 的 最 新 提交 上 。 


$git svn rebase 

Rebuilding.git/svn/refs/remotes/trunk/.rev_map.f79726c4-f016- 
41bd-acd5-6c9ac 

b7664b2... 

ri=2c73d657dfc3alceca9d465b0b98f9e123b92bb4 

r2=1863f91b45def159a3ed2c4c4c9428c25213f956 

r5=fae6dab863ed2152f71bcb2348d476d47194fdd4 


r6=doeb86bdfad4720e0a24edc49ec2b52e50473e83 

r7=69f4aa56eb96230aedd7c643f65d03b618ccc9e5 

Done 

rebuilding.git/svn/refs/remotes/trunk/.rev_map.f79726c4-f016- 
41bd-acd5-6c9ac 

b7664b2 

Current branch master is up to date. 


如 果 执 行 git svn fetch 则 会 对 所 有 的 分 支 都 进行 重建 。 


$git svn fetch 

Rebuilding.git/svn/refs/remotes/demo-1.0/.rev_map.f79726c4-f016- 
41bd-acd5-6c 

9acb7664b2... 

r3=1adcd5526976fe2a796d932ff92d6c41b7eedcc4 

r8=a8b32d1b533d308bef59101c1f2c9a16baf91e48 

Done 

rebuilding.git/svn/refs/remotes/demo-1.0/.rev_map.f79726c4-f016- 
41bd-acd5-6c 

9acb7664b2 

Rebuilding.git/svn/refs/remotes/tags/v1.0/.rev_map.f79726c4- 
f016-41bd-acd5-6c 

9acb7664b2... 

r4=c1i2aa40c494b495a846e73ab5a3c787calad81e9 

Done 

rebuilding.git/svn/refs/remotes/tags/v1.0/.rev_map.f79726c4- 
fo016-41bd-acd5-6 

c9acb7664b2 


至 此 ， 从 gitrsvn 克 隆 库 二 次 克隆 的 Git 库 ， 已 经 和 原生 的 git-svn 库 
一 样 使 用 git-svn 命 令 了 。 


26.5 ”git-svn 的 局 限 


Subversion 和 Git 的 分 文 实现 有 着 巨大 的 不 同 。Subversion 的 分 文 和 
里 程 碑 ， 是 用 轻 量 级 搓 贝 实现 的 ， 虽 然 创建 分 文 和 里 程 碑 的 速度 也 很 
快 ， 但 是 很 难 维护 。 即 使 Subversion 在 1.5 之 后 引入 了 svn:mergeinfo 属 性 
对 合并 过 程 进 行 标 记 ， 但 是 也 不 可 能 让 Subversion 的 分 文 逻 辑 更 清晰 。 
git-svn 无 须 利 用 syn:mergeinfo 属 性 也 可 实现 对 Subversion 合 并 的 追踪 ， 
在 合并 的 时 候 也 不 会 对 svn:mergeinfo 属 性 进行 更 改 ， 因 此 在 使 用 git- 
svn 操 作 时 ， 如 果 在 不 同 分 文 间 进行 合并 ， 会 导致 Subversion 的 
svn:mergeinfo 属 性 没有 相应 的 更 新 ， 从 而 导致 Subversion 用 户 进行 合并 
时 因为 重复 合并 而 冲突 。 


人 简 而 言 之 ， 在 使 用 git-svn 时 尽量 不 要 在 不 同 的 分 支 之 间 进 行 合 
并 ， 而 是 尽量 在 一 个 分 支 下 进行 线性 的 提交 。 这 种 线性 的 提交 会 很 好 
地 推送 到 Subversion 服 务 器 中 。 


如 果真 的 需要 在 不 同 的 Subversion 分 文 之 间 合 并 ， 尽 量 使 用 
Subversion 的 客户 端 (svn 1.5 版 本 或 以 上 ) 执行 ， 因 为 这 样 可 以 正确 地 
记录 svn:mergeinfo 属 性 。 当 Subversion 完 成 分 支 合 并 后 ， 在 git-svn 的 克 
笨 库 中 执行 git svn rebase 命 令 获 取 最 新 的 Subversion 提 交 并 变 基 到 相应 
的 跟 踩 分 文中 。 


第 5 篇 “搭建 Git 服 务 硕 


如 果 不 是 要 和 他 人 协同 开发 ，Git 根 本 就 不 需要 以 设 服务 右 ， 因 为 
Git 可 以 直接 使 用 本 地 路 径 操作 本 地 的 版 本 库 及 完成 本 地 版 本 库 间 的 协 
局 车 


但 是 如 果 和 需要 和 他 人 分 至 版 本 库 、 协 作 开发 ， 或 者 想 要 通过 网 络 
为 个 人 的 版 本 库 建立 一 个 远程 容 灾 备份 ， 号 会 涉及 服务 絮 搭 建 ， 以 及 
使 用 特定 的 网 络 协议 操作 Git 库 。 


Git 文 持 的 协议 很 丰富 ， 架 设 服务 右 的 移 择 也 很 多 ， 不 同 的 方案 有 
着 各 目的 优 缺 后， 如 下 表 所 示 。 


Git 服务 器 架设 方案 对 照 表 
HTTP Ot-dacmon SSH Citosis/Gitolite 
服务 架设 j | j 生 复 
匿名 读 取 妇 玫 妆 寺 本 
千 份 认 订 i 儿 持 妇 持 


注 : *SSH 协 议和 基于 SSH 的 Gitolite 等 可 以 通过 空 口令 账号 实现 匿 
名 访问 。 


第 27 章 ”使 用 HTTP 协 议 


HTTP 协议 是 版 本 控制 非常 重要 的 一 种 协议 ， 具 有 安全 (使 用 
HTTPS 的 情况 下 ) 、 方 便 〈 可 以 跨越 防火 墙 ) 等 优点 。Git 在 1.6.6 版 本 
之 前 对 HTTP 协 议 的 支持 有 限 ， 是 吧 协 议 ， 访 问 效率 低 ， 但 是 在 1.6.6 之 
后 ， 通 过 一 个 CGI 实现 了 智能 的 HITP 协 议 支 持 。 


27.1 哑 传 输 协 议 


在 Git 1.6.6 之 前 ， 若 要 通过 HTTP 协 议 提供 Git 服 务 ， 简 单 到 直接 搂 
贝 Git 版 本 库 到 Web 服 务 器 中 就 可 以 了 ， 即 将 Git 的 裸 版 本 库 (不 带 工 作 
区 ) 作为 一 个 web 静态 目录 直接 开放 给 用 户 即 可 局 。 


1. 只 读 的 HITP 哑 协议 


如 下 的 Apache 配 置 ， 提 供 了 Git 版 本 库 的 只 读 访问 服务 : 


Alias/git/path/to/repos 
<Directory/path/to/repos> 
Options FollowSymLinks 
AllowOverride None 

Order allow, deny 

Allow from all 
</Directory> 


当 用 户 执 行 git clone http://server/git/myrepo.git 上 时 ， 实 际 访问 的 是 服 


已 


务 贺 端 /pathyto/repos/myrepo.git 路 径 中 的 版 本 库 。 


以 web 服务 器 静态 目录 方式 提供 Git 服 务 ， 对 Git 版 本 库 有 一 个 特别 
的 要 求 ， 即 版 本 库 目 录 下 必须 存在 两 个 索引 文件 。 其 中 一 个 是 
件 .gitinfo/refs， 包 含 了 版 本 库 中 所 有 引用 的 列表 ， 且 包含 引用 对 应 的 
SHA1 哈 希 值 。 另 外 一 个 文件 是 .git/objects/info/packs， 包 含 了 所 有 打包 
文件 的 路 径 ， 以 便 在 对 象 库 打 包 后 ， 能 够 通过 该 索引 文件 找到 打包 文 
人 作 汪 


这 是 因为 在 Web 旺 协议 下 ， 作 为 客户 端的 Git 类 似 于 一 个 Web 浏览 
器 ， 远 程 的 Web 服 务 器 只 提供 Git 版 本 库 文件 的 静态 访问 ， 而 不 像 其 他 
Git 知 能 服务 器 那样 能 够 提供 帮助 以 获取 Git 版 本 库 的 引用 和 对 象 库 文 
件 。 即 作为 Web 客 户 端 的 Git 仅 凭 一己 之 力主 动 到 服务 器 上 抓 取 文件 。 
一 旦 严格 配置 的 Web 服务 器 禁止 目录 浏览 (最 安全 和 最 常用 的 配 
置 ) ， 如 果 不 通过 事先 约定 的 索引 文件 (.git/info/refs 
和 .git/objects/info/packs 文 件 ) ，Git 作 为 Web 客 户 端 是 无 法 获得 版 本 库 
的 引用 列表 和 打包 文件 列表 的 。 


在 Git 版 本 库 中 创建 这 两 个 索引 文件 很 简单 ， 只 要 执行 git update- 
server-info 命 令 即 可 。 但 是 要 随 着 版 本 库 的 更 新 不 断 地 维护 .giUinfo/refs 
和 .git/objects/info/packs 这 几 个 文件 ， 以 便 使 用 哑 协 议 的 Git 客 户 端 始终 
能 够 正常 地 访问 Git 版 本 库 可 不 是 一 件 简单 的 工作 。 洱 好 Git 提 供 了 钓 
子 脚 本 扩展 机 制 ， 可 以 实现 随 着 Git 版 本 库 的 更 新 闻 步 地 更 改 这 几 个 文 
件 。 


在 版 本 库 的 钧 子 脚 本 目录 .git/hooks 中 ， 创 建 一 个 名 为 post-update 
的 钩子 脚本 。 实 际 上 在 钩子 脚本 的 目 孙 中 已 经 存在 一 个 示例 脚本 post- 
update.sample， 直 接 将 其 重 命名 为 postrupdate， 并 将 其 设置 为 可 执行 即 
可 。 脚 本 post-update 非 常 简单 ， 内 容 如 下 : 


#!/bin/sh 
exec git update-server-info 


2. 可 读 写 的 HTTP 呈 协议 


上 面 配置 的 HTTP 呈 协议 只 提供 Git 版 本 库 的 只 读 访问 ， 如 有 果 需 
提供 可 写 的 Git 版 本 库 服务 ， 即 允许 远程 客户 端 推 送 ， 那 束 还 需要 在 
Apache 中 为 版 本 库 逐 一 启用 WebDAV 支 持 。 例 如 Apache 中 的 配置 如 
下 : 


Alias/git/path/to/repos 
<Directory/path/to/repos> 
Options FollowSymLinks 
AllowOverride None 

Order allow, deny 

allow from all 

</Directory> 
<Location/git/myrepos.git> 

DAV on 

AuthType Basic 

AuthName "Git" 

AuthBasicProvider file 
AuthUserFile/path/to/file/passwd 
AuthGroupFile/path/to/file/group 
Require group git 

Satisfy All 

</Location> 


无 论 是 只 读 还 是 支持 写 入 ， 以 HTTP 哑 传输 协议 配置 的 Git 服 务 器 
都 有 看 非常 明显 的 缺点 : 


(1) 数据 传输 效率 低 。 当 版 本 库 经 过 整理 ， 各 个 零散 的 提交 文件 
被 打包 后 ， 只 获取 某 一 个 或 某 几 个 提交 也 需要 对 整个 打包 文件 进行 传 


输 ! 


(2) 传输 过 程 无 进度 显示 。 呈 协议 在 Git 操 作 过 程 中 不 能 像 其 他 
协议 那样 显示 进度 ， 在 操作 大 的 版 本 库 时 非常 不 便 。 


(3) 为 版 本 库 提 供 写 操作 需要 对 每 个 版 本 库 进 行 单独 配置 。 缺 乏 
类 似 Subversion 的 WebDAV 插 件 ， 使 得 需要 为 每 个 Git 库 逐一 进行 设 
置 o 


(4) 需要 在 服务 器 端 手工 创建 版 本 库 ， 而 不 能 通过 远程 推送 操作 
来 实现 在 客户 端 发 起 版 本 库 的 创建 。 


(5) Git 客 户 端 不 像 Subversion 那 样 提 供 口 令 缓 存 机 制 ， 如 果 要 避 
免 每 次 操作 时 频繁 地 输入 口令 ， 需 要 在 URL 中 记录 明文 口令 。 


git clone 
https://username:password@server/path/to/repos/myrepo.git 


下 面 将 要 介绍 的 智能 HTTP 协 议 则 没有 上 面 所 述 的 大 多 数 1、2 和 3 
缺点 ， 在 很 大 程度 上 完善 了 在 HTTP 协 议 上 架设 Git 版 本 库 的 用 户 体 


验 。 


[1] 实际 上 还 需要 执行 git update-server-info 命 令 ， 以 更 新 版 本 库 中 的 几 
个 索引 文件 。 


27.2 ”智能 HTTP 协 议 


Git 1.6.6 之 后 的 版 本 提供 了 针对 HTTP 协 议 的 CGI 程序 git-http- 
backend， 实 现 了 智能 的 HITP 协 议 文 持 。 但 同时 要 求 Git 客 户 端的 版 本 
不 低 于 1.6.6。 


查看 文件 git-http-backend 的 安装 位 置 ， 可 以 用 如 下 命令 。 


$1ls$(git--exec-path)/git-http-backend 
/usr/l1ib/git-core/git-http-backend 


更 改 Apache 的 配置 文件 ， 以 使 用 CGI 提供 智能 Git 访 问 服 务 。 相 关 
的 Apache 配 置 如 下 : 


SetEnv GIT_PROJECT_ROOT/path/to/repos 
SetEnv GIT_HTTP_EXPORT_ALL 
ScriptAlias/git//usr/lib/git-core/git-http-backend/ 


说 明 : 


一 行 设 置 版 本 库 的 根 目录 为 /path/to/repos 。 


第 二 行 设 置 所 有 版 本 库 均 可 访问 ， 无 论 在 版 本 库 中 是 否 存在 git- 
daemon-export-ok 文 件 。 


该 版 


默认 只 有 在 版 本 库 目 录 中 存在 git-daemon-export-ok 文 件 时 ， 
本 库 才 可 以 访问 。 这 个 文件 是 git-daemon 服 务 的 一 个 特性 


第 三 行 ， 束 是 使 用 名 为 git-http-backend 的 CGI 脚 本 来 啊 应 客户 端的 


请 求 。 当 访问 http://server/git/myrepos.git 时 ， 即 由 此 CGI 提 供 服务 
1. 写 操作 授权 


上 面 的 配置 只 能 提供 版 本 库 的 读 取 服务 ， 帮 想 提供 基于 HTTP 协 议 
的 写 操作 ， 必 须 添 加 认证 配置 指令 。 用 户 通 过 认证 后 才能 对 版 本 库 进 


行 写 操作 。 
下 面 的 Apache 配 置 中 ， 在 前 面 配置 的 基础 上 为 Git 写 操作 提供 授 


权 : 


<LocationMatch "^/git/.*/git-receive-pack$" 


AuthType Basic 
AuthName "Git Access" 
AuthBasicProvider file 
AuthUserFile/path/to/passwd/file 


</LocationMatch> 


2. 读 和 写 均 需 授权 


如 采 需 要 对 读 操 作 也 进行 授权 ， 那 吏 更 简单 了 。 下 面 的 配置 通过 


一 个 Location 语 句 实现 了 对 路 人 径 /path/private 下 版 本 库 的 读 写 授权 。 


<Location/git/private> 

AuthType Basic 

AuthName "Git Access" 
AuthBasicProvider file 
AuthUserFile/path/to/passwd/file 


</Location> 


3. 对 静态 文件 的 直接 访问 


如 采 对 静态 文件 的 访问 不 经 过 CGI 程序 ， 直 接 由 Apache 提 供 服 


务 ， 会 提高 访问 性 能 。 


下 面 的 Apache 配 置 设 置 了 直接 通过 Apache 〈 绕 过 CGI) 访问 Git 版 
本 库 中 对 象 库 下 的 文件 。 


SetEnv GIT_PROJECT_ROOT/path/to/repos 
AliasMatch^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f] 
{38})$/path/to/repos/$1 
AliasMatch^/git/(.*/objects/pack/pack-[0-9a-f]{40}. 
(pack|idx))$/path/to/repos/$1 
ScriptAlias/git//usr/libexec/git-core/git-http-backend/ 


Git 的 智能 HTTP 上 服务 彻底 打破 了 以 前 哑 传 输 协 议 给 HTTP 协 议 带 来 
的 恶劣 印象 ， 让 HTTP 协 议 成 为 Git 服 务 的 一 个 重要 选项 。 但 是 在 授权 


的 管理 上 ， 知 能 HTTP 服 务 仅仅 依赖 Apache 目 身 的 授权 模型 ， 相 比 后 
面 要 介绍 的 Gitosis 和 Gitolite， 可 管理 性 要 弱 得 多 。 表 现 如 下 : 


创建 版 本 库 只 能 在 服务 器 端 进行 ， 不 能 通过 远程 客户 端 进行 。 


配置 认证 和 授权 ， 也 只 能 在 服务 硕 端 进行 ， 不 能 在 客户 端 远程 配 
署 。 


版 本 库 的 写 操作 授权 只 能 进行 非 0 即 1 的 授权 ， 不 能 针对 分 文 甚至 
路 径 进行 授权 。 


如 果 需 要 企业 级 的 版 本 库 管 理 ， 可 以 考虑 后 面 介 绍 的 基于 SSH 协 
议 的 Gitolite 或 Gitosis 。 


27.3 ”Gitweb 服 务 器 


前 面 介绍 的 HTTP 哑 协议 和 知 能 协议 服务 染 设 ， 都 可 以 用 于 提供 
Git 版 本 库 的 读 写 服 务 ， 而 本 节 介 绍 的 Gitweb 作 为 一 个 Web 应 用 ， 只 提 
供 版 本 库 的 图 形 化 浏 览 功能 ， 而 不 能 提供 版 


本 库 读 写 访 问 的 功能 .。 

Gitweb 是 用 Perl 语言 开发 的 CGI 靶 本 ， 既 可 以 通过 配置 架设 于 Web 服务 器 下 ， 也 可 以 
无 须 任何 配置 针对 单独 Git 版 本 库 即 时 启动 。Gitweb 支持 多 个 版 本 库 ， 可 以 对 版 本 库 进行 目 
录 浏 览 ( 包 插 历史 版 本 )， 可 以 查看 文件 内 容 ， 查 看 提交 历史 ， 提 供 搜 索 及 RSS feed 支持 ， 
也 可 以 提供 目录 文件 的 打包 下 载 等 。 图 27-1 就 是 kernel.org 上 的 Gitweb 示例 。 
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图 27-1 Gitweb 界面 (“kernel,org) 


27.3.1 ”Gitweb 的 安装 


1. 使 用 包 管 理 器 安装 

各 个 Linux 平台 大 都 提供 了 Gitweb 软件 包 ， 可 以 使 用 相应 的 包 管 理 器 进行 安装 。 例 如 
在 Debian/Ubuntu 上 安装 Gitweb ; 

SS sudo aptitude install gitweb 

安装 Gitweb 后 人 ee 系统 中 创建 下 列 文件 

口 配 置 文件 : Le/gitweb,.con 

口 Apache 配置 +: /etc/apache2/conf .d/git 

口 CGI 脚 本 ; /usr/share/gitweb/index.cgi 

口 其 他 附属 文件 ; /usr/share/gitweb/* 


口 图 片 和 css 等 
其 中 配置 文件 /etc/apache2/conf,d/gitweb 用 于 完成 和 Web 服务 器 Apache2 的 


索 合 Apache2 重启 后 ， 就 可 以 通过 URL 地 址 hitp:Wserver/gitweb 访问 Gitweb 服务 


2. 使 用 Git 源 码 安 装 


Gitweb 的 代码 位 于 Git 的 源码 库 中 ， 如 果 Git 是 从 源码 进行 安装 的 ， 
那么 Gitweb 应 该 已 经 安装 好 了 。 通 过 下 面 的 命令 可 以 查看 Gitweb 的 安 


装 位 置 : 


$1s-F$(dirname$ (dirname$(git--html-path)))/gitweb 


gitweb.cgi*static/ 
$echo$(dirname$ (dirname$(git--html-path)))/gitweb 


/usr/share/gitweb 


Gitweb 里 然 已 经 安装 ， 但 是 尚未 和 Web 服 务 絮 整合 。 在 Apache 的 
配置 文件 中 添加 如 下 配置 ， 重 启 Apache 后 ， 即 可 以 用 地 址 /gitweb 来 访 


问 Gitweb 服 务 。 


Alias/gitweb/usr/share/gitweb 

<Directory/usr/share/gitweb> 

Options FollowSymLinks+ExecCGI 
AddHandler cgi-script.cgi 


DirectoryIndex index.cgi gitweb.cgi 
Order Allow,Deny 

Allow from all 

</Directory> 


27.3.2 ”Gitweb 的 配置 


编辑 /etc/gitweb.conf， 更 改 Gitweb 的 默认 设置 : 
版 本 库 的 根 日 录 。 


$projectroot="/var/cache/git"; 


设置 版 本 库 访 问 URL 。 


Gitweb 可 以 为 每 个 版 本 库 显 示 殉 隆 该 版 本 库 的 URL 地 址 ， 可 以 设 


@git_base_url list= 
("git://bj.ossxp.com/git","http://bj.ossxp.com/git"); 


设置 站 页 模板 文件 。 该 文件 为 HTML 格 式 ， 其 内 容 将 显示 在 首页 
上 “。 如 果 使 用 相对 路 径 ， 则 相对 于 CGI 脚本 所 在 的 目录 。 


$home_ text="indextext.html"; 


定制 首页 模板 。 下 面 古 我 公司 内 部 使 用 的 Gitweb 首 页 模板 。 


<html> 
<head> 
</head> 
<body> 


<h2> 北 系 群 瑞 汇 信息 技术 有 限 公 司 -git 代 码 库 </h2> 

<ul> 

<1i> 点 击 版 本 库 , 进入 相应 的 版 本 库 页 面 , 有 URL 指 向 一 个 git : /7/.. .的 检 出 链接 
</1i> 

<1i> 使 用 命令 git clone git://,. .来 克隆 一 个 版 本 库 < /1i > 

0 gitsvn< /> 字样 的 代码 民 FE, 是 用 git-svn 从 svn 代 码 
库 镜 像 而 来 的 。 

对 于 它们 的 镜像 , 需要 做 进一步 的 工作 。 

<ul> 

<1i> 要 将 git 库 的 远程 分 支 ( ,git/ref/remotes/*) 也 同步 到 本 地 ! 

<pre> 

$git config--add remote.origin.fetch 
'+refs/remotes/*:refs/remotes/*' 

$git fetch 

</pre> 

</1i> 

<1i> 如 果 需 要 克隆 库 和 Subversion 同 步 。 用 git-svn 初 始 化 代码 库 , 并 使 得 相关 配 
置 和 源 保 持 一 致 </1i> 

</ul> 

</1i> 

</ul> 

</body> 

</html> 


版 本 库 列 表 。 


默认 扫 拉 版 本 库 根 目录 查找 版 本 库 。 如 果 版 本 库 非 常 I 
找 过 程 可 能 很 耗 时 ， 可 以 提供 一 个 文本 文件 包含 版 本 库 的 列表 加 速 
Gitweb 显 示 初 始 化 。 


$projects_list="/home/git/gitosis/projects.1ist"; 


后 面 介绍 的 Gitosis 和 Gitolite 都 可 以 目 动 生成 这 么 一 个 版 本 库 列 
表 ， 供 Gitweb 使 用 。 


Gitweb 荣 单 定制 。 


Git 菜 单 定 制 项 很 多 ， 下 面 选 取 几 个 典型 配置 进行 介绍 。 
O 在 tree view 文 件 的 旁边 显示 追溯 (blame) 链接 。 


$feature{'blame'}{'default'}=[1]:; 
$feature{'blame'}{'override'}=1; 


过 版 本 库 的 配置 文件 config 对 版 本 库 在 Gitweb 中 是 否 显 示 退 济 


进行 单独 设置 。 


下 面 的 设置 覆 兰 Gitweb 的 全 局 设置 ， 不 对 该 项 目 显示 blame 沫 单 。 


[gitweb] 
blame=0 


O 为 每 个 tree 添 加 快照 (snapshot) 下 载 链 接 。 


$feature{'snapshot'}{'default'}=['zip', 'tgz']; 
$feature{'snapshot'}{"'override'}=1:; 


27.3.3 ”版 本 库 的 Gitweb 相 天 设置 


可 以 通过 Git 版 本 库 下 的 配置 文件 ， 定 制版 本 库 在 Gitweb 下 的 显 


文件 description 。 
提供 一 行 简 短 的 Git 库 描述 ， 显 示 在 Gitweb 版 本 库 列 表 中 。 


也 可 以 通过 config 配 置 文件 中 的 gitweb.description 进 行 设 置 ， 但 是 
文件 优先 。 


文件 README.html 。 

提供 更 详细 的 项 目 描述 ， 显 示 在 Gitweb 项 目 页 面 中 。 
文件 cloneurl 。 

版 本 库 访 问 的 URL 地 址 ， 一 行 一 个 。 

文件 config。 


通过 [gitweb] 小 太 的 配置 ， 徐 盖 Gitweb 的 全 局 设置 : 


Ogitweb.owner 用 于 显示 版 本 库 的 创建 者 。 


Ogitweb.description 显 示 项 目的 简短 描述 ， 也 可 以 通过 description 


文件 来 提供 (这 件 优 完 ) 


O gitweb.url 显 示 项 目的 URL 列 表 ， 也 可 以 通过 cloneurl 文 件 来 提 
供 。 (文件 优先 ) 


27.3.4 ”即时 Gitweb 服 务 


如 果 安 装 有 lighttpd 站 一 一 轻 量 级 Web 服 务 器 ， 甚 至 可 以 无 须 任 何 
配置 ， 当 在 工作 区 中 运行 下 面 的 命令 时 ， 自 动用 Web 浏 览 器 打开 URL 
地 址 : http:/127.0.0.1:1234/， 访 问 即 时 启动 的 Gitweb 服 务 。 


$git instaweb 


可 以 通过 Git 配 置 变 量 对 即时 局 动 的 Gitweb 服 务 进行 设置 ， 例 如 用 
instaweb.port 配 置 变量 设置 默认 Web 服 务 端口 (默认 为 1234) 


[1| http:/www.lighttpd.net/ 


第 28 章 ”使 用 Git 协 议 

Git 协 议 是 提供 Git 版 本 库 只 读 服务 的 最 常用 的 协议 ， 也 是 非常 易 
用 和 易于 配置 的 协议 。 该 协议 的 缺点 就 是 不 能 提供 身份 认证 ， 而 且 一 
般 也 不 提供 写 入 服务 。 


28.1 Git 协议 语法 格式 


Git 协 议 的 语法 格式 如 下 。 


语法 :git://<server>[:<port>]/path/to/repos.git/ 
说 明 : 
端口 为 可 选项 ， 默 认 端 口 为 9418。 


版 本 库 路 人 径 /path/to/repos.git 的 根 目录 并 不 一 定 是 系统 的 根 目 录 ， 
可 以 在 git-daemon 启 动 时 用 参数 --base-path 来 指定 根 上 日 录 。 如 果 git- 
daemon 没 有 设置 根 目 录 ， 则 对 应 于 系统 的 根 目 录 。 


28.2 ”Git 服 务 软件 


Git 服 务 由 名 为 git-daemon 的 服务 软件 提供 。 虽 然 git-daemon 也 可 以 
支持 写 操作 ， 但 因为 git-daemon 没 有 提供 认证 支持 ， 因 此 很 少 有 人 胆 
敢 配 置 git-daemon 来 提供 匿名 的 写 服务 。 使 用 git-daemon 提 供 的 Git 版 本 
库 只 读 服务 效率 很 高 ， 而 且 是 一 种 智能 协议 ， 操 作 过 程 有 进度 显示 ， 
远 比 HTTP 呈 通信 协议 方便 (Git 1.6.6 之 后 的 版 本 已 经 支持 智能 HTTP 通 
信 协 议 ) 。 因 此 git-daemon 很 久 以 来 ， 一 直 是 Git 版 本 库 只 读 服 务 的 首 
] 先 。 


Git 软 件 包 本 号 提供 了 gitrdaemon， 因 此 只 要 安装 了 Git， 一 般 束 已 
经 安装 了 git-daemon。 默 认 git-daemon 并 没有 运行 ， 需 要 对 其 进行 配 
， 以 服务 的 方式 运行 。 下 面 介绍 两 种 不 同 的 配置 运行 方式 。 


28.3 ”以 inetd 方 式 配 置 运行 


最 简单 的 方式 是 以 inetd 服 务 的 方式 运行 gitrdaemon。 在 配置 文 
件 /etc/inetd.conf 中 添加 如 下 设置 : 


git stream tcp nowait nobody/usr/bin/git 
git daemon--inetd--verbose--export-all 
/gitroot/foo/gitroot/bar 


说 明 : 
以 nobody 用 户 吴 份 执行 git daemon 服 务 。 


默认 git-daemon 只 对 包含 文件 git-daemon-export-ok 的 版 本 库 提供 服 


名 
务 。 使 用 参数 --export-all 后 ， 无 论 版 本 库 是 否 存 在 标识 文件 git-daemon- 
export-ok， 都 对 版 本 库 提供 Git 访 问 服务 。 


后 面 的 两 个 参数 是 版 本 库 根 目录 ， 用 户 只 可 以 访问 指定 目录 下 的 
Git 版 本 库 。 
例如 可 以 访问 git://server/gitroot/foo/project1.git 和 


git://server/gitroot/bar/project2.git， 但 是 git://server/others/project3.git 是 


访问 不 到 的 。 


如 果 版 本 库 的 路 径 比 较 深 ， 有 什么 办 法 能 在 用 户 访问 时 提供 短 一 
些 的 URL 地 址 呢 ? 可 以 使 用 参数 --base-path=<path> 建立 版 本 库 根 目 
录 映 里 ， 例 如 下 面 的 inetd 的 配置 : 


git stream tcp nowait nobody/usr/bin/git 
git daemon--inetd--verbose--export-all 
--base-path=/var/cache/var/cache/git 


在 上 面 的 配置 中 ， 设 置 提供 版 本 库 服 务 的 路 径 为 /var/cache/git， 但 
为 配置 了 --base-path=/var/cache 参 数 ， 在 实际 访问 时 用 户 所 请 求 的 Git 
版 本 库 路 径 都 会 添加 这 个 前 级 ， 然 后 再 到 指定 的 目录 中 去 寻找 。 例 如 
当 用 户 访问 git://server/git/myrepos.git 了 时 ， 实 际 访问 的 路 径 


是 /Var/cache/git/myrepos.git 。 


28.4 ”以 runit 方 式 配 置 运行 


runit1 | 是 类 似 于 sysvinit 的 服务 管理 进程 ， 但 是 更 为 简单 。 在 


Debian/Ubuntu 上 的 软件 包 git-daemon-run 就 是 基于 runit 启 动 git-daemon 


服务 。 
安装 git-daemon-run: 
$sudo aptitude install git-daemon-run 
配置 git-daemon-run: 


默认 的 服务 配置 文件 : /etc/swgit-daemonrun。 和 之 前 的 inetd 运 行 
方式 相 比 ， 以 独立 的 服务 进程 启动 ， 速 度 更 快 。 


#!/bin/sh 

exec 2>&1 

echo 'git-daemon starting,.' 

exec chpst-ugitdaemon\ 
"$(git--exec-path)"/git-daemon--verbose--export-all\ 
--base-path=/var/cache/var/cache/git 


默认 版 本 库 中 需要 存在 文件 git-daemon-export-ok,git-daemon 才 对 
此 版 本 库 提供 服务 。 不 过 可 以 通过 启动 git-daemon 时 提供 的 参数 -- 
export-all， 无 论 版 本 库 是 否 存 在 标识 文件 git-daemon-export-ok， 都 对 
版 本 库 提供 git 访 问 服务 。 


git-daemon 提 供 很 多 参数 ， 在 此 没有 一 一 介绍 ， 可 以 运行 git help 
daemon 在 控制 台 查 看 git-daemon 帮 助 ， 或 者 运行 git help--web daemon 查 
看 HTML 格 式 的 帮助 。 


通过 git-daemon 提 供 的 Git 访 问 协议 存在 着 局 限 性 : 


不 文 持 认证 。 管 理 员 可 以 做 的 大 概 只 是 配置 防火 墙 ， 限制 茶 个 网 
段 用 户 的 使 用 。 


只 能 提供 匿名 的 版 本 库 读 取 服 务 。 因 为 写 操 作 没 有 授权 控制 ， 
此 一 般 不 用 来 提供 写 操作 。 


[1| http://smarden.org/runit/ 


第 29 章 ”使 用 SSH 人 协议 


SSH 协 议 用 于 为 Git 提 供 远程 读 写 操作 ， 是 远程 写 操作 的 标准 服 
务 ， 在 智能 HITTP 协 议 出 现 之 前 ， 甚 至 是 写 操作 的 唯一 标准 服务 。 


29.1 SSH 协 议 语法 格式 


对 于 拥有 shell 登 录 权 限 的 用 户 账号 ， 可 以 用 下 面 的 语法 访问 Git 版 
本 库 : 


语法 1:ssh://[<username>@] <server>[:<port 
>]/path/to/repos/myrepo.git 
语法 2: [<username>@] <server>:/path/to/repos/myrepo.git 


说 明 : 


SSH 协 议 地 址 格式 可 以 使 用 两 种 不 同 的 写法 ， 第 一 种 是 使 用 ssh:/ 
开头 的 标准 的 SSH 协 议 UREL 写 法 ， 另 外 一 种 是 SCP 格 式 的 写法 。 


两 种 写法 均 可 ，SSH 协 议 标 准 URL 写 法 稍 嫌 复杂 ， 但 是 对 于 非 标 
准 SSH 端 口 〈 非 22 端 口 ) ， 可 以 通过 URL 给 出 端口 号 。 


<username> 是 服务 器 <server> 上 的 用 户 账 号 。 


如 果 省 略 用 户 名 ， 则 默认 使 用 当前 登录 用 户 名 (配置 和 使 用 了 主 
机 别名 的 除外 ) 。 


<port> 为 SSH 协 议 端口 ， 默 认为 22。 


为 只 有 语法 1 才能 在 URL 中 提供 端口 ， 因 此 如 有 果 使 用 非 默认 端口 
22， 最 好 使 用 语法 1。 当 然 使 用 语法 2 也 可 以 实现 ， 但 是 要 通过 
~/.ssh/config 配 置 文件 设置 主机 别名 。 


路 径 /path/to/repos/myrepo.git 是 服务 右 中 版 本 库 的 绝对 路 径 。 知 用 
相对 路 径 则 是 相对 于 username 用 户 的 主 目 孙 而 言 的 。 


如 果 采 用 口令 认证 ， 不 能 像 HTTPS 协 议 那 样 可 以 在 URL 中 同时 给 
出 登录 名 和 口令 ， 必 须 在 每 次 连接 时 输入 口令 。 


如 果 采 用 公 钥 认证 ， 则 无 须 输 入 口令 。 


29.2 服务 架设 方式 比较 


SSH 协 议 有 两 种 方式 来 实现 Git 服 务 。 第 一 种 是 用 标准 的 SSH 账 号 
访问 版 本 库 。 即 用 户 账号 可 以 直接 登录 到 服务 器 获得 shell。 对 于 这 种 
使 用 标准 SSH 账 号 的 方式 ， 直 接 使 用 标准 的 SSH 服 务 就 可 以 了 ， 无 须 


第 二 种 实现 方式 是 所 有 用 户 都 使 用 同一 个 专用 的 SSH 账 号 访问 版 
本 库 ， 访 问 时 通过 公 钥 认证 的 方式 。 昌 然 所 有 用 户 用 同一 个 账号 访 
问 ， 但 可 以 通过 在 建立 连接 时 所 用 的 不 同 公 钥 来 区 分 不 同 的 用 户 身 
份 。Gitosis 和 Gitolite 束 古 实 现 该 方式 的 两 个 服务 器 软件 。 


标准 SSH 账 号 和 专用 SSH 账 号 这 两 种 实现 方式 的 区 别 见 表 29-1。 


表 29-1 不 同 SSH 服务 架设 方式 对 照 表 


标准 SSH Gitosis/Gitolite 
账号 每 个 用 户 一 个 账号 所 有 用 户 共用 同一 个 账号 
计 证 方式 口令 或 公 钥 认证 公 钥 认证 
苹 录 到 shell 是 否 
安全 性 基 
管理 员 需 要 shell 是 百 
版 本 库 路 径 相对 路 径 或 钨 对 路 径 相对 路 径 
授权 方式 操作 系统 中 用 户 组 和 目录 权限 通过 配置 文件 授权 
分 支 写 授权 本 Gitolite 
路 径 写 授权 看 Gitolite 


条 设 难 易 度 简单 复杂 


实际 上 ， 标 准 SSH 也 可 以 用 公 钥 认证 的 方式 实现 所 有 用 户 共 用 同 
一 个 账号 ， 不 过 这 类 似 于 把 一 个 公共 账号 的 登录 口令 同时 告诉 给 多 个 
人 。 具 体操 作 过 程 如 下 : 


(1) 在 服务 器 端 (server) 创建 一 个 公共 账号 ， 例 如 


anonymous ° 


(2) 管理 员 收 集 需 要 访问 git 服 务 的 用 户 公 钥 。 如 : userl.pub、 


user2.pub ° 


(3) 使 用 ssh-copy-id 命 令 将 各 个 git 用 户 的 公 钥 远程 加 入 服务 器 
(server) 的 公 钥 认证 列表 中 。 


远程 操作 ， 可 以 使 用 ssh-copy-id 命 令 。 


$ssh-copy-id-i user1.pub anonymousQ@server 
$ssh-copy-id-i user2.pub anonymous@server 


如 有 果 直 接 在 服务 器 上 操作 ， 则 直接 将 文件 退 加 全 authorized_keys 
区 伯 申 :3 


$cat/path/to/user1.pub> ~>~anonymous/.ssh/authorized_keys 
$cat/path/to/user2.pub>>~anonymous/.ssh/authorized_keys 


(4) 在 服务 器 端的 anonymous 用 户主 目录 下 建立 git 库 ， 就 可 以 实 
现 多 个 用 户 利 用 同一 个 系统 账号 (anonymous) 访问 Git 服 务 了 。 


这 样 做 除了 不 必 逐 一 设置 账号 ， 以 及 用 户 无 须 口令 认证 之 外 ， 标 
准 SSH 部 车 Git 服 务 的 缺点 一 个 也 不 少 ， 而 且 因 为 用 户 之 间 无 法 区 分 ， 
更 无 法 针对 用 户 进行 授权 。 


下 面 重 点 介绍 一 下 SSH 公 钥 认 证 ， 因 为 它们 是 后 面 即将 介绍 的 
Gitosis 和 Gitolite 服 务 絮 软件 的 基础 。 


29.3 ”关于 SSH 公 钥 认 证 


SSH 公 钥 认 证 是 一 种 非常 安全 且 免 口令 的 认证 方式 。 天 于 公 铀 认 
证 的 原理 ， 维 基 百 科 上 的 这 个 条 目 是 一 个 很 好 的 起 点 : 


http://en.wikipedia.org/wiki/Public-key_cryptography 


为 实现 公 钥 认证 ， 作 为 认证 的 客户 端 一 方 需要 拥有 两 个 文件 ， 即 
公 钥 / 私 钥 对 。 一 般 公 钥 / 私 钥 对 文件 创建 在 用 户 的 主 目 孙 下 的 .sh 目录 
中 。 如 果 用 户主 目录 下 不 存在 .ssh 目 录 ， 说 明 SSH 公 钥 / 私 钥 对 尚未 创 
建 。 可 以 用 下 面 的 这 个 命令 创建 : 


$ssh-keygen 


该 命令 会 在 用 户主 目录 下 创建 .ssh 目录， 并 在 其 中 创建 两 个 文件 ; 


id_rsa 


私 钥 文 件 。 坪 基于 RSA 算 法 创建 的 。 该 私 钥 文件 要 习 善 保管 不 要 


id_rsa.pub 


公 钥 文件 。 和 id_rsa 文 件 是 一 对 儿 ， 该 文件 作为 公 钼 文件 可 以 公 
着 


创建 了 自己 的 公 铀 / 私 钥 对 后 ， 就 可 以 使 用 下 面 的 命令 ， 实 现 无 口 
令 登录 远程 服务 器 ， 即 用 公 钥 认证 取代 口令 认证 。 


$ssh-copy-id-i,.ssh/id_rsa.pub<user >@< server> 
说 明 : 
该 命令 会 提示 输入 用 户 user 在 server 上 的 SSH 登 录 口 令 。 


此 命令 执行 成 功 后 ， 再 以 user 用 户 用 ssh 命 令 登录 server 远 程 主机 
上 时， 不 必 输 入 口令 可 直接 登录 。 


该 命令 实际 上 是 将 .ssh/id_rsa.pub 公 钥 文 件 妃 加 到 远程 主机 server 的 
user 主 日 录 下 的 .ssh/authorized_keys 文 件 中 。 


检查 公 角 认证 是 否 生 效 ， 通 过 ssh 命 令 连 接 远 程 主机 ， 正 常 的 话 应 
该 直接 登录 成 功 。 如 采 要 求 输入 口令 则 表明 公 角 认证 配置 存在 问题 。 
如 有 果 SSH 登 录 存 在 问题 ， 可 以 通过 查看 服务 絮 端 的 /var/log/auth.log 日 志 
文件 进行 诊断 。 


29.4 关于 SSH 主 机 别名 


在 实际 应 用 中 ， 有 时 需要 使 用 多 套 公 钥 / 私 钥 对 ， 例 如 : 


使 用 默认 的 公 钥 访问 服务 器 的 git 账 号 ， 可 以 执行 git 命 令 ， 但 不 能 
进行 shell 登 录 。 

使 用 特别 创建 的 公 钥 访问 服务 絮 的 git 账 号 ， 能 够 获取 shell， 登 录 
后 可 以 对 Git 服 务 器 软件 进行 升级 、 维 护 等 工作 。 


访问 Github 《免费 的 Git 服 务 托管 商 ) 使 用 其 他 公 钥 ( 非 默 认 公 
|) 


从 上 面 的 说 明 中 可 以 看 出 ， 用 户 可 能 拥有 不 只 一 套 公 钥 / 私 钥 对 。 
为 了 创建 不 同 的 公 钥 / 私 钥 对 ， 在 使 用 ssh-keygen 命 令 时 残 需 要 通过 -{ 参 
数 指定 不 同 的 私 钥 名 称 。 用 法 如 下 : 


$ssh-keygen-f~/.ssh/<filename> 


请 将 <filename> 替换 为 有 意义 的 名 称 。 命 令 执 行 完 毕 后 ， 会 在 
~/.sSsh 目 了 永 下 创建 指定 的 公 钥 / 私 钥 对 : 文件 <filename> 是 私 铀 ， 文 


件 <filename>.pub 是 公 钥 。 


将 新 生成 的 公 钥 添 加 到 远程 主机 登录 用 户主 目录 下 
的 .sshyauthorized_keys 文 件 中 ， 融 可 以 使 用 新 创建 的 公 钥 建立 到 远程 主 
机 <server> 的 <user> 账 户 的 无 口令 登录 〈 采 用 公 钥 认证 ) 。 操作 如 
下 : 


$ssh-copy-id-i,.ssh/<filename> .pub<user>@<server> 


现在 用 户 存在 多 个 公 钼 / 私 钥 对 ， 那 么 当 执行 下 面 的 ssh 登 水 指 令 
时 ， 用 到 的 是 哪个 公 钥 呢 ? 


$ssh<user >@<server> 


当然 是 默认 公 钥 ~/.sshMyid_rsa.pub。 那 么 如 何 用 新建 的 公 钥 连接 


server 呢 ? 


SSH 的 客户 端 配 置 文件 ~/.ssh/config 可 以 通过 创建 主机 别名 ， 在 连 
接 主 机 时 选择 使 用 特定 的 公 钥 。 例 如 一 /ssh/config 文 件 中 的 下 列 配 
置 : 
host bj 
user git 
hostname bj.ossxp.com 


port 22 
identityfile~/.ssh/jiangxin 


执行 下 面 的 SSH 登 录 命 令 : 


$ssh bj 


或 者 执行 下 面 的 Git 命 令 : 


$git clone bj:path/to/repos/myrepo.git 


虽然 这 两 条 命令 各 不 相同 ， 但 是 都 使 用 了 SSH 协 议 ， 以 及 相同 的 
主机 别名 : bj。 参 考 上 面 在 ~/.ssh/config 文 件 中 建立 的 主机 别名 ， 可 以 
做 出 如 下 判断 : 


登录 的 SSH 主 机 名 为 bj.ossxp.com 。 
登录 时 使 用 的 用 户 名 为 git。 


认证 时 使 用 的 公 钥 文件 为 ~/.ssh/jiangxin.pub。 


第 30 章 ”Gitolite 服 务 架 设 


Gitolite 是 一 款 Perl 语 言 开发 的 Git 服 务 管理 工具 ， 通 过 公 钥 对 用 户 
进行 认证 ， 并 能 够 通过 配置 文件 对 写 操 作 进 行 基于 分 文 和 路 径 的 精细 
授权 。Gitolite 采 用 的 是 SSH 协 议 并 且 使 用 SSH 公 钥 认 证 ， 因 此 无 论 是 
管理 员 还 是 普通 用 户 ， 都 需要 对 SSH 非 常熟 悉 。 在 开始 之 前 ， 请 确认 
您 已 经 通读 过 第 29 章 “使 用 SSH 协 议 ”。 


Gitolite 的 官方 网 址 是 : http:Wgithub.comy/sitaramc/gitolite。 从 提交 
日 志 里 可 以 看 出 作者 是 Sitaram Chamarty， 最 早 的 提交 开始 于 2009 年 8 
月 。 作 者 是 受到 了 Gitosis 的 启发 ， 开 发 了 这 款 功能 更 为 强大 和 易于 安 
装 的 软件 。Gitolite 的 命名 ， 作 者 的 原意 是 Gitosis 和 lite 的 组 合 ， 不 过 因 
为 Gitolite 的 功能 越 来 越 强大 ， 已 经 超越 了 Gitosis， 因 此 作者 笑称 
Gitolite 可 以 看 作 是 Github-lite 一 一 轻 量 级 的 Github。 


我 是 在 2010 年 8 月 才 发 现 Gitolite 这 个 项 目的 ， 并 壬 试 将 公司 基于 
Gitosis 的 管理 系统 迁移 至 Gitolite。 在 迁移 和 使 用 过 程 中 ， 增 加 和 改进 
了 一 些 实现 ， 如 : 通配符 版 本 库 的 创建 过 程 ， 对 创建 者 的 授权 ， 版 本 
库 名 称 上 映射 等 。 本 文 关 于 Gitolite 的 介绍 也 是 基于 我 改进 的 版 本 由。 


原作 者 的 版 本 库 地 址 : 


http://github.com/sitaramc/gitolite 


笔者 改进 后 的 Gitolite 分 文 : 

http://github.com/ossxp-com/gitolite 

Gitolite 的 实现 机 制 和 使 用 特点 概述 如 下 : 

Gitolite 安 装 在 服务 右 (server) 的 某 个 账号 之 下 ， 例 如 git 帐 号 。 
管理 员 通 过 git 命 令 检 出 名 为 gitolite-admin 的 版 本 库 。 
$git clone git@server:gitolite-admin.git 


理 员 将 Git 用 户 的 公 钥 保存 在 gitolite-admin 库 的 keydir 目 未 下 ， 并 


编辑 conf/gitolite.conf 文 件 为 用 户 授权 。 


当 管理 员 提交 对 gitolite-admin 库 的 修改 并 推送 到 服务 器 之 后 ， 服 
务 器 上 gitolite-admin 版 本 库 的 钧 子 脚本 将 执行 相应 的 设置 工作 。 


O 新 用 户 的 公 钥 目 动 追加 到 服务 右 端 安 洲 账号 主 目录 下 


的 .ssh/authorized_ 


keys 文 件 中 ， 并 设置 该 用 户 的 shell 为 gitolite 的 一 条 命令 gl-auth- 


command。 在 .ssh/authorized_keys 文 件 中 增加 的 内 容 示 例如 下 : 


command="/home/git/ .gitolite/src/gl-auth-command 
Jiangxin",no-port-forwarding,no-X11-forwarding,no-agent- 


forwarding,no- 


pty ssh-rsa AAAAB3NzaC1yc2. . . ( 公 钥 内 容 来 自 于 jiangxin.pub)..， [2] 


O 更 新 服务 器 端的 授权 文件 ~/.gitolite/conf/gitolite.conf 。 
oO 编译 授权 文件 为 ~/.gitolite/conf/gitolite.conf-compiled.pm。 


若 用 ssh 命 令 登 录 服 务 器 (以 Git 用 户 登 录 ) 时 ， 因 为 公 钥 认证 的 
相关 设置 〈 使 用 gl-auth-command 作 为 shell) ， 不 能 进入 shell 环 境 ， 而 
是 打印 服务 器 端 Git 库 授权 信息 后 马上 退出 。 即 用 户 不 会 通过 Git 用 户 
进入 服务 器 的 shell， 也 不 会 对 系统 的 安全 造成 威胁 。 


$ssh git@bj 

hello jiangxin,the gitolite version here is v1.5.5-9-g4c1i1ibd8 
the gitolite config gives you the following access: 

R gistore-bj.ossxp.com/.*$ 

C R W ossxp/.*$ 

Q@CQ@R W users/jiangxin/.+$ 

Connection to bj closed., 


用 户 可 以 用 git 命 令 访问 授权 的 版 本 库 。 
铬 绾 理 员 授 权 ， 用 户 可 以 远程 在 服务 右上 创建 新 版 本 库 。 
下 面 介 绍 Gitolite 的 部 署 和 使 用 。 在 下 面 的 示例 中 约定 : 服务 右 的 


名 称 为 server,Gitolite 的 安装 账号 为 git， 管 理 员 的 ID 为 admin 。 


30.1 ”安装 Gitolite 


Gitolite 要 求 Git 的 版 本 必须 是 1.6.2 或 以 上 的 版 本 ， 并 且 服 务 器 要 提 
供 SSH 服 务 。 下 面 是 Gitolite 的 安装 过 程 。 


30.1.1 服务 器 问 创 建 专 用 账号 


安装 Gitolite， 首 先 要 在 服务 器 端 创 建 专用 账号 ， 所 有 用 户 都 通过 
此 账号 访问 Git 库 。 一 般 为 方便 易 记 ， 选 择 git 作 为 专用 账号 名 称 。 


$sudo adduser--system--shell/bin/bash--group git 


创建 用 户 git， 并 设置 用 户 的 shell 为 可 登录 的 shell， 如 /bin/bash， 同 
时 添加 同名 的 用 户 组 。 


有 的 系统 ， 只 允许 特定 用 户 组 《如 ssh 用 户 组 ) 的 用 户 才 可 以 通过 
SSH 协 议 登 录 ， 这 号 需要 将 新 建 的 git 用 户 同 时 也 添加 到 该 特定 的 用 户 
组 中 。 执 行 下 面 的 命令 可 以 将 git 用 户 深 加 a 到 ssh 用 户 组 。 


$sudo adduser git ssh 


为 git 用 户 设 置 口 令 。 当 整个 git 服 务 配 置 完成 ， 运 行 正常 后 ， 建 议 
取消 git 的 口令 ， 只 人 允许 公 钥 认证 。 


$sudo passwd git 


理 员 在 客户 端 使 用 下 面 的 命令 ， 建 立 无 口令 登录 : 


$ssh-copy-id git@server 


至 此 ， 已 经 完成 了 安装 git 服 务 的 准备 工作 ， 可 以 开始 安 逆 Gitolite 
服务 软件 了 。 


[对 Gitolite 的 各 项 改动 采用 了 Topgit 特 性 分 支 进行 维护 ， 以 便 与 上 游 
的 最 新 代码 同步 更 新 。 还 要 注意 ， 如 采 使 用 Gitolite 时 发 现 问题 ， 要 区 
分 是 由 上 游 软 件 引发 的 ， 还 是 因为 我 的 改动 引起 的 ， 不 要 把 我 的 错误 
算 在 Sitaram 头 上 。;-) 

[2] 本 段 内 容 为 一 整 行 ， 因 排版 需要 做 了 换行 处 理 。 


30.1.2 ”Gitolite 的 安装 /升级 


本 市 的 标题 为 安装 /升级 ， 是 因为 Gitolite 的 安 疾 和 升级 可 以 采用 同 
样 的 步骤 。 


Gitolite 安 装 可 以 在 客户 端 执 行 ， 而 不 需要 在 服务 器 端 操作 ， 非 常 
方便 。 远 程 安装 Gitolite 的 前 提 是 : 


已 经 在 服务 右 端 创建 了 专 有 账号 ， 如 git 。 


管理 员 能 够 以 git 用 户 的 号 份 通过 公 钥 认证 以 无 口令 方式 登录 服务 


安装 和 升级 都 可 以 按照 下 面 的 步骤 进行 : 
(1) 使 用 git 下 载 Gitolite 的 源 代 码 。 
$git clone git://github.com/ossxp-com/gitolite.git 
(2) 进入 gitolite/src 目 录 ， 执 行 安 装 。 


$cd gitolite/src 
$./gl-easy-install] git server admin 


命令 gl-easy-install 的 第 一 个 参数 git 是 服务 器 上 创建 的 专用 账号 


ID， 第 二 个 参数 server 是 服务 器 了 PP 或 域名 ， 第 三 个 参数 admin 是 管理 员 


(3) 首先 显示 版 本 信息 。 


you are upgrading(or installing first-time)to v1.5.4-22-g4024621 

Note:getting '(unknown)' for the 'from' version should only 
happen once. 

Getting '(unknown)' for the 'to' version means you are probably 
installing 

from a tar file dump,not a real clone.This is not an error but 
it's nice to 

have those version numbers in case you need support.Try and 
install from a clone 


(4) 目 动 创建 名 为 admin 的 私 钥 / 公 钥 对 。 创 建 的 公 钥 / 私 钥 对 的 


名 称 来 自 于 gl-easy-install 命 令 的 最 后 一 个 参数 admin 。 


the next command will create a new keypair for your gitolite 
access 

The pubkey will be/home/jiangxin/.ssh/admin.pub.You will have to 
choose a 

passphrase or hit enter for none.I recommend not having a 
passphrase for 

now, *especially*if you do not have a passphrase for the key 
which you are 

already using to get server access! 

Add one using 'ssh-keygen-p' after all the setup is done and 
you've 

successfully cloned and pushed the gitolite-admin repo.After 
that,install 


'keychain' or something similar,and add the following command to 
your bashrc 

(since this is a non-default key) 

ssh-add$HOME/ .ssh/admin 

This makes using passphrases very convenient. 


(5) 如 果 公 钥 已 经 存在 ， 会 弹出 警告 。 


Hmmm., .pubkey/home/jiangxin/.ssh/admin.pub exists; should I 
just(re-)use it? 

IMPORTANT:once the install completes,*this*key can no longer be 
used to get 

a command line on the server--it will be used by gitolite,for 
git access 

only.If that is a problem,please ABORT now. 

doc/6-ssh-troubleshooting.mkd will explain what is happening 
here,if you need 

more info. 


(6) 自动 修改 客户 端的 .ssh/config 文 件 ， 增 加 名 为 gitolite 的 别名 
下放 


即 当 访问 主机 gitolite 时 ， 会 目 动用 名 为 admin.pub 的 公 铀 ， 以 git 用 
户 的 身份 连接 服务 器 。 


creating settings for your gitolite access 
in/home/jiangxin/ .ssh/config; 

these are the lines that will be appended to your~/.ssh/config: 

host gitolite 

user git 

hostname server 

port 22 

identityfile~/.ssh/admin 


(7) 上 传 脚本 文件 到 服务 器 ， 完 成 服务 器 端 软件 的 安装 。 


gl-dont-panic 

100%3106 3.0KB/s 00:00 
gl-conf-convert 
100%2325 2.3KB/s 00:00 
gl-setup-authkeys 
100%1572 1.5KB/s 00:00 


gitolite-hooked 

100%0 0.0KB/s 00:00 
update 

100%4922 4.8KB/s 00:00 


the gitolite rc file needs to be edited by hand.The defaults are 
sensible, 

so if you wish,you can just exit the editor. 

Otherwise,make any changes you wish and save it.Read the 
comments to 

understand what is what--the rc file's documentation is inline. 

Please remember this file will actually be copied to the 
server,and that all 

the paths etc.represent paths on the server! 


(8) 自动 调用 vi 编辑 器 打开 .gitolite.rc 文 件 ， 编 辑 结束 后 上 传 到 服 


0 


口 恒 


dR 


该 配置 文件 为 Perl 语 法 ， 注 意 保 持 文件 格式 和 语法 。 退 出 vi 编辑 
器 ， 输 入 "<ESC>:q" (不 带 引 号 ) 。 以 下 为 该 配置 文件 中 比较 重要 的 
设置 ， 一 般 无 须 改变 默认 的 配置 。 


O$REPO_BASE="repositories"; 


用 于 设置 Git 服 务 句 的 根 目 录 ， 默 认 是 Git 用 户主 目录 下 的 
repositories 目 录 ， 可 以 使 用 绝对 路 笃 。 所 有 Git 库 都 将 部 署 在 该 目录 
证 


O$REPO_ UMASK=0007; #gets yOu rTWXrWX---' 
版 本 库 创 建 使 用 的 掩 码 。 即 新 建立 的 版 本 库 的 权限 为 TWxrwx---'。 
DGL BIG CONFIG=0; 


如 果 授 权 文 件 非常 复 沫 ， 更 改 此 项 配置 为 1， 以 免 产 生 庞 大 的 授权 
编译 文件 。 


O $GL_WILDREPOS=1; 
上 默认 文 持 通配符 版 本 库 授 权 。 


(9) 至 此 完成 安装 。 


30.1.3 ”关于 SSH 主 机 别名 


在 安装 过 程 中 ，gitolite 创 建 了 名 为 admin 的 公 钥 / 私 钥 对 ， 以 名 为 
admin.pub 的 公 钥 连接 服务 器 的 git 帐 户 ， 使 用 由 gitolite 提 供 的 Git 服 务 。 
但 是 如 果 直 接连 接 服务 妖 ， 使 用 的 是 默认 的 公 钥 ， 会 直接 进入 shell。 


那么 如 何 能 够 根据 需要 选择 不 同 的 公 钥 来 连接 git 服 务 右 呢 ? 


别 志 了 在 前 面 介绍 过 的 SSH 主 机 别名 。 实 际 上 刚刚 在 安 狠 gitolite 
的 时 候 ， 束 已 经 目 动 地 创建 了 一 个 主机 别名 。 打 开 ~/.ssh/config 文 件 
可 以 看 到 类 似 内 容 ， 如 果 对 主机 别名 不 满意 可 以 修改 。 


host gitolite 

user git 

hostname server 

port 22 
identityfile~/.ssh/admin 


中 : 


像 下 面 这 样 输 入 SSH 命 令 会 直接 进入 shell， 因 为 使 用 的 是 默认 的 
公 避 * 


$ssh git@server 


像 下 面 这 样 输入 SSH 命 令 则 不 会 进入 shell。 因 为 使 用 名 为 
admin.pub 的 公 铀 ， 会 显示 Git 授 权 信 息 并 马上 退出 。 


$ssh gitolite 


30.1.4 ”其 他 的 安装 方法 


上 面 介绍 的 是 在 客户 端 远 程 安装 Gitolite， 是 最 音 用 和 推荐 的 方 
法 。 当 然 还 可 以 直接 在 服务 器 上 安装 ， 具 体操 作 过 程 如 下 。 


(1) 首先 也 要 在 服务 器 端 先 创建 一 个 专用 的 账 瑟 ， 如 git 。 


$sudo adduser--system--shell/bin/bash--group git 


(2) 将 管理 员 公 钥 复 制 到 服务 器 上 。 
理 员 在 客户 端 执行 下 面 的 命令 


$scp~/.ssh/id_rsa.pub server:/tmp/admin.pub 


(3) 服务 器 端 安装 Gitolite (源码 方式 安装 ) 。 


站 上 


推荐 采用 源码 方式 安装 ， 因 为 如 果 以 平台 自 带 软件 包 模 式 安装 
Gitolite， 那 么 其 中 就 不 包含 我 对 Gitolite 的 改进 


使 用 git 下 载 Gitolite 的 源 代码 。 


$git clone git://github.com/ossxp-com/gitolite.git 


创建 目录 。 


$sudo mkdir-p/usr/local/share/gitolite/conf\ 
/usr/local/share/gitolite/hooks 


进入 gitolite/src 目 录 ， 执 行 安装 。 


$cd gitolite/src 
$sudo./gl-system-install/usr/local/bin\ 
/usr/local/share/gitolite/conf\ 
/usr/local/share/gitolite/hooks 


安装 完毕 跳 到 步 怠 5。 
(4) 服务 器 端 安装 Gitolite (平台 包 管 理 器 安装 ) 。 


如 采 不 选择 从 源 代码 进行 安装 (如 步 又 3) ， 也 可 以 使 用 当前 平台 
的 包 管 理 器 进行 安装 。 例 如 在 Debian/Ubuntu 平 台 执 行 下 面 的 命令 : 


$sudo aptitude install gitolite 


(5) 在 服务 器 端 以 专用 账号 执行 安装 脚本 。 


例如 服务 絮 端 的 专用 账号 为 git， 先 执行 su 命令 ， 临 时 切换 到 该 用 
户 ， 继 续 下 面 的 安装 。 


$sudo su-git 
$g1-setup/tmp/admin.pub 


(6) 管理 员 在 客户 端 克 隆 gitolite-admin 库 。 


$git clone git@server:gitolite-admin 


(7) 在 克隆 出 来 的 gitolite-admin 工 作 区 中 ， 以 Git 的 方式 管理 
gitolite。 如 添加 、 删 除 用 户 帐号， 设置 用 户 权限 。 


升级 Gitolite 只 需要 执行 上 面 的 步骤 3 或 步骤 4 即 可 完成 升级 。 如 采 
还 修改 或 增加 了 新 的 钩子 脚本 ， 还 需要 重新 执行 步骤 5。Gitolite 的 升 
级 有 可 能 要 求 修 改 配置 文件 : ~/.gitolite.rc 。 


30.2 ”管理 Gitolite 


30.2.1 管理 员 克 隆 gitolite-admin 管 理 库 


当 Gitolite 安 闭 完 成 后 ， 在 服务 器 端 目 动 创建 了 一 个 用 于 Gitolite 目 
吴 管 理 的 Git 库 : gitolite-admin.git 。 


克隆 gitolite-admin.git 库 。 别 忘 了 使 用 SSH 主 机 别名 : 


$git clone gitolite:gitolite-admin.git 

Initialized empty Git repository in/data/tmp/gitolite- 
admin/ .git/ 

remote:Counting objects:6,done. 

remote:Compressing objects:100%(4/4),done. 

remote:Total 6(delta 0),reused 0(delta 0) 

Receiving objects:100%(6/6),done. 

$cd gitolite-admin/ 

$1s-F 

conf/keydir/ 

$1s conf 

gitolite.conf 

$1s keydir/ 

admin.pub 


可 以 看 出 gitolite-admin 目 隶 下 有 两 个 目录 conf/ 和 keydir/。 
keydir/admin.pub 文 件 


目录 keydir 下 初始 时 只 有 一 个 用 户 公 钥 ， 即 amdin 用 户 的 公 钥 。 


conf/gitolite.conf 文 件 
该 文件 为 授权 文件 。 初 始 内 容 为 : 


#gitolite conf 


#please see conf/example.conf for details on syntax and features 
repo gitolite-admin 

RW+=admin 

repo testing 

RW+=@all 


默认 授权 文件 中 只 设置 了 两 个 版 本 库 的 授权 : 
gitolite-admin 


即 本 版 本 库 (gitolite 管 理 版 本 库 ) 中 只 有 admin 用 户 有 读 写 和 强制 
更 新 的 权限 。 


testing 


默认 设置 的 测试 版 本 库 ， 设 置 为 任何 人 都 可 以 读 写 及 强制 更 新 。 


30.2.2 ”增加 新 用 户 


增加 新 用 户 ， 就 是 允许 新 用 户 能 够 通过 其 公 钥 访问 Git 服 务 。 只 
将 新 用 户 的 公 钥 添加 到 gitolite-admin 版 本 库 的 keydir 目 未 下 ， 即 完成 新 
用 户 的 添加 ， 有 具体 操作 过 程 如 下 。 


(1) 管理 员 从 用 户 获 取 公 铀 ， 并 将 公 钥 按照 username.pub 格 式 进 
行 重 命名 。 


用 户 可 以 通过 邮件 或 其 他 方式 将 公 钥 传递 给 管理 员 ， 切 记 不 要 将 
私 钥 误 传 给 管理 员 。 如 果 发 生 私 钥 和 泄漏， 马上 重新 生成 新 的 公 钥 / 私 钥 
对 ， 并 将 新 的 公 钥 传递 给 管理 员 ， 并 申请 将 旧 的 公 钥 作废 。 


用 户 从 不 同 的 客户 端 主机 访问 有 着 不 同 的 公 铀 ， 如 果 硕 望 使 用 同 
一 个 用 户 名 进行 授权 ， 可 以 按照 uIsemame@host.pub 的 方式 命名 公 钥 文 
件 ， 和 名 为 username.pub 的 公 钥 指 同 同一 个 用 户 username 。 


Gitolite 也 支持 邮件 地 址 格式 的 公 钥 ， 即 形 如 
usernameOgmail.com.pub 的 公 铀 。Gitolite 能 够 很 智能 地 区 分 是 以 邮件 
地 址 命名 的 公 钥 还 是 相同 用 户 在 不 同 主机 上 的 公 铀 。 如 果 是 邮件 地 址 
命名 的 公 钥 ， 将 以 整个 邮件 地 址 作为 用 户 名 。 


(2) 管理 员 进 入 gitolite-admin 本 地 克隆 版 本 库 中 ， 复 制 新 用 户 公 
钥 到 keydir 目 录 。 


$cp/path/to/devi.pub keydir/ 
$cp/path/to/dev2.pub keydir/ 
$cp/path/to/jiangxin.pub keydir/ 


(3) 执行 git add 命 令 ， 将 公 钥 添加 到 版 本 库 。 


$git add keydir 

$git status 

#0n branch master 

#Changes to be committed: 

#(UusSe "git reset HEAD<file>..."to unstage) 
# 

#new file:keydir/devi.pub 

#new file:keydir/dev2.pub 

#new file:keydir/jiangxin.pub 

# 


(4) 执行 git commit， 完 成 提交 。 


$git commit-m "add user:jiangxin,devi,dev2" 
[master bd81884]add user:jiangxin,devi1, dev2 

3 files changed,3 insertions(+),0 deletions(-) 
create mode 100644 keydir/devi.pub 

create mode 100644 keydir/dev2.pub 

create mode 100644 keydir/jiangxin.pub 


(5) 执行 git push， 同 步 到 服务 器 ， 才 真正 完成 新 用 户 的 添加 。 


$git push 

Counting objects:8,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(6/6),done. 


Writing objects:100%(6/6),1.38 KiB, done. 
Total 6(delta 0),reused 0O(delta 0) 
remote:Already on'master' 

remote: 

remote:*****WARNING***** 


remote:the following users(pubkey files in parens)do not appear 


in the config file: 


remote:devi(devi.pub),dev2(dev2.pub),jiangxin(jiangxin.pub) 


如 有 果 这 时 查看 服务 器 端 git 用 户主 目录 下 的 .ssh/authorized_keys 文 


件 ， 会 发 现 新 增 的 用 户 公 钥 也 附加 在 其 中 : 


$cat~git/.ssh/authorized_keys 

#gitolite start 

command="/home/git/ .gitolite/src/gl-auth-command 

admin",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty<< 用 户 

admin 的 公 钥 .. .> 

command="/home/git/ .gitolite/src/gl-auth-command 

devi",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty<< 用 户 

dev1I 的 公 钥 ,,, > 

command="/home/git/ .gitolite/src/gl-auth-command 

dev2",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty< 用 户 

dev2 的 公 钥 .,. > 

command="/home/git/ .gitolite/src/gl-auth-command 


Jiangxin",no-port-forwarding,no-X11-forwarding,no-agent- 


forwarding,no-pty<< 用 户 
jiangxin 的 公 铀 ,, ,> 
#gitolite end 


在 之 前 执行 git push 后 的 输出 中 ， 以 remote 标 识 的 输出 是 服务 硕 端 


执行 post-update 钧 子 脚 本 的 输出 。 其 中 的 警告 是 说 新 添加 的 三 个 用 户 


在 授权 文件 中 没有 被 引用 。 接 下 来 便 看 看 如 何 修改 授权 文件 ， 以 及 如 
何 为 用 户 添加 授权 。 


30.2.3 ”更 改 授 权 


新 用 户 添 加 完毕 ， 可 能 需要 重新 进行 授权 。 更 改 授权 的 方法 也 非 
常 简单 ， 即 修改 conf/gitolite.conf 配 置 文件 ， 提 交 并 推送 ， 具 体操 作 过 
程 如 下 。 


(1) 管理 员 进 入 gitolite-admin 本 地 克隆 版 本 库 中 ， 编 辑 


conf/gitolite.conf ° 


$vi conf/gitolite.conf 


(2) 授权 指令 比较 复杂 ， 先 通过 建立 新 用 户 组 尝试 一 下 更 改 授 权 
Xs 


著 虑 到 之 前 增加 了 三 个 用 户 公 钥 ， 服 务 器 端 发 出 了 用 户 尚 未 在 授 
权 文件 中 出 现 的 警告 。 现 在 束 在 这 个 示例 中 解决 这 个 问题 。 


可 以 在 其 中 加 入 用 户 组 @team1， 将 新 添加 的 用 户 jiangxin、 
dev1、dev2 都 归属 到 这 个 组 中 。 只 需要 在 conf/gitolite.conf 文 件 的 文件 
头 加 入 如 下 指令 即 可 。 用 户 名 之 间 用 空格 分 隔 。 


Qteam1=dev1 dev2 jiangxin 


还 修改 了 版 本 库 testing 的 授权 ， 将 @all 用 户 组 改 为 新 建立 的 


@team1 用 户 组 。 从 编辑 完毕 后 的 文件 差异 输出 可 以 看 到 相关 改动 。 


wt 
洗 


$git diff 

diff--git a/conf/gitolite.conf b/conf/gitolite.conf 
index 6c5fdf8..f983a84 100644 
---a/conf/gitolite.conf 

+++b/conf/gitolite.conf 

@@-1,10+1, 12@@ 

#gitolite conf 


#please see conf/example.conf for details on syntax and features 


+Q@team1=dev1 dev2 jiangxin 
+ 

repo gitolite-admin 
RW+=admin 

repo testing 

-RW+=@all 

+RW+=@team1 


(3) 编辑 结束 ， 提 交 改 动 。 


$git add conf/gitolite.conf 
$git commit-q-m "new teamQ@team1 auth for repo testing." 


(4) 执行 git push， 同 步 到 服务 器 ， 授 权 文 件 的 更 改 才 真正 生 


可 以 注意 到 ， 推 送 后 的 输出 中 没有 了 警告 。 


$git push 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(3/3),done. 
Writing objects:100%(4/4),398 bytes, done. 
Total 4(delta 1),reused 0O(delta 0) 
remote:Already on 'master' 


To gitadmin.bj:gitolite-admin.git 
bd81884. .79b29e4 master->master 


30.3 ”Gitolite 授 权 详 解 


30.3.1 授权 文件 的 基本 语法 


下 面 看 一 个 不 那么 简单 的 授权 文件 。 为 方便 描述 汪 、 加 了 行 号 。 


@admin=jiangxin wangsheng 


repo gitolite-admin 
RW+=jiangxin 


repo ossxp/.+ 
C=@admin 
RW=@all 


OROOORODP 


10 repo testing 

11 RW+=@admin 

12 RW master=junio 

13 RW+pu=junio 

14 RW cogito$=pasky 

15 RW bw/=linus 

16 -=somebody 

17 RW tmp/=@all 

18 RW refs/tags/v[0-9]=junio 


在 上 面 的 示例 中 ,演示 了 很 多 授权 指令 : 


第 1 行 ， 定义 了 用 户 组 @admin， 包 含 两 个 用 户 jiangxin 和 


wangsheng ° 


第 3~-4 行 ， 定 义 了 版 本 库 gitolite-admin。 并 指定 只 有 用 户 jiangxin 
才能 够 访问 ， 并 拥有 读 (R) 写 (W) 和 强制 更 新 (+) 的 权限 。 


第 6 行 ， 通 过 正则 表达 式 定 义 了 一 组 版 本 库 ， 即 在 ossxp/ 目 孙 下 的 
所 有 版 本 库 。 


第 7 行 ， 用 户 组 @admin 中 的 用 户 ， 可 以 在 ossxp/ 目 永 下 创建 版 本 
库 。 创 建 版 本 库 的 用 户 ， 具 有 对 版 本 库 操作 的 所 有 权限 。 


第 8 行 ， 所 有 用 户 都 可 以 读 写 ossxp 目 录 下 的 版 本 库 ， 但 不 能 强制 
更 新 。 


第 10 行 开始 ， 定 义 的 testing 版 本 库 授 权 使 用 了 引用 授权 语法 。 


第 11 行 ， 用 户 组 @admin 对 所 有 的 分 文 和 里 程 碑 拥 有 读 写 、 重 置 、 
添加 和 删除 的 授权 。 


第 12 行 ， 用 户 junio 可 以 读 写 master 分 支 。 (还 包括 名 字 以 master 开 
头 的 其 他 分 支 ， 如 果 有 的 话 。) 


第 13 行 ， 用 户 junio 可 以 读 写 、 强 制 更 新 、 创 建 及 删除 pu 开头 的 分 


第 14 行 ， 用 户 pasky 可 以 读 写 cogito 分 支 。 ( 仅 此 分 支 ， 精 确 匹 
配 ) 。 


30.3.2 ”定义 用 户 组 和 版 本 库 组 


在 conf/gitolite.conf 授 权 文 件 中 ， 可 以 定义 用 户 组 或 版 本 库 组 。 组 
名 称 以 @ 字 符 开头 ， 可 以 包含 一 个 或 多 个 成 员 。 成 员 之 间 用 空格 分 
Ee 


例如 定义 管理 员 组 : 


@admin=jiangxin wangsheng 


组 可 以 敬 套 : 


@staff=@admin@engineers tester1 


除了 作为 用 户 组 外 ， 同 样 的 语法 也 适用 于 版 本 库 组 。 


版 本 库 组 和 用 户 组 的 定义 没有 任何 区 别 ， 只 是 在 版 本 库 授权 指令 
中 处 于 不 同 的 位 置 。 即 位 于 授权 指令 中 的 版 本 库 位 置 代 表 版 本 库 组 ， 
位 于 要 人 懈 指 们 丰 的 用 户 伍 站 代表 用 月 风 


30.3.3 ”版 本 库 ACL 


一 个 版 本 库 可 以 包含 多 条 授权 指令 ， 这 些 授权 指令 组 成 了 一 个 版 
本 库 的 权限 控制 列表 (ACL) 。 例 如 : 


repo testing 
RW+=jiangxin@admin 
RW=@dev@test 
R=@all 


1. 版 本 库 
每 一 个 版 本 库 授 权 都 以 一 条 repo 指 令 开 始 。 


指令 repo 后 面 古 版 本 库 列 表 ， 版 本 之 间 用 空格 分 开 ， 还 可 以 包括 
版 本 库 组 。 


注意 : 版 本 库 名 称 不 要 添加 .git 后 绥 。 在 版 本 库 创 建 过 程 中 会 自动 
添加 .git 后 组 。 


repo sandbox/test1 sandbox/test2@test_repos 


用 repo 指 令 设置 的 版 本 库 会 自动 在 服务 器 上 创建 ， 但 是 如 采 repo 
指令 后 面 的 版 本 库 名 称 中 包含 通配符 ， 则 不 会 自动 创建 。 


repo 指 令 后 面 的 版 本 库 名称 中 可 以 使 用 正则 表达 式 ， 这 种 用 正则 
表达 式 定 义 的 版 本 库 称 为 通配符 版 本 库 。 


在 Gitolite 对 用 户 访问 版 本 库 名 称 进 行 匹配 时 ， 会 自动 给 看 似 通 配 
符 版 本 库 的 名 称 加 上 前 缀 ^ 和 后 缀 $。 这 一 点 和 后 面 将 要 介绍 的 正则 引 
用 (refex) 大 不 一 样 。 


repo ossxp/.+ 


不 过 有 时 候 使 用 了 过 于 简单 的 正则 表达 式 ， 如 "myrepo."， 有 可 能 
会 产生 歧义 ， 让 Gitolite 将 希望 用 正则 表达 式 表 示 的 通配符 版 本 库 误 判 
为 普通 版 本 库 名 称 ， 在 服务 釉 端 目 动 创建 名 为 myrepo..git 的 版 本 库 。 
解决 上 疏 义 的 一 个 办 法 是 :在 正则 表达 式 的 前 面 明确 地 插入 ^ 符 号 ， 或 者 
在 表达 式 后 面 添加 $ 符 号 ， 形 如 : "^myrepo."、"myrepo.$"， 

或 "Amyrepo.$"。 


2 人 忆 提 人 


在 repo 指 令 之 后 是 缩 进 的 一 条 或 多 条 授权 指令 。 授 权 指 令 的 语法 
如 下 : 


< 权限 > [ 零 个 或 多 个 正则 表达 式 匹 配 的 引用 ]=<user>[<user>...] 


每 条 指令 必须 指定 一 个 权限 。 权 限 可 以 用 下 面 任意 一 个 权限 关键 


学 


C、R、RW、RW+、RWC、RW+C、RWD、RW+D、RWCD、RW+CD。 


权限 后 面包 含 一 个 可 选 的 正则 引用 (refex) 列表 。 


正则 表达 式 格式 的 引用 ， 简 称 正 则 引用 (refex) ， 对 Git 版 本 库 的 
引用 〈 分 文 、 里 程 碑 等 ) 进行 匹配 。 


如 果 在 授权 指令 中 省 略 正则 引用 ， 则 意味 着 对 全 部 的 Git3| 用 (分 
支 、 里 程 碑 等 ) 都 有 效 。 正 则 引用 如 果 不 以 refs/ 开 头 ， 会 自动 添加 
refs/heads/ 作 为 前 级 。 


正则 引用 如 果 不 以 $ 结 尾 ， 则 意味 着 后 面 可 以 匹配 任意 字符 ， 相 当 
于 添加 .*$ 作 为 后 缀 。 


权限 后 面 也 可 以 包含 一 个 以 NAME/ 为 前 缀 的 路 径 列表 ， 进 行 基于 
路 径 的 授权 。 


授权 指令 以 等 号 (=) 为 标记 分 为 前 后 两 段 ， 等 号 后 面 的 是 用 户 
列表 。 用 户 之 间 用 空格 分 隅 ， 并 且 可 以 使 用 用 户 组 。 


3. 授 权 关 键 字 


不 同 的 授权 关键 字 有 不 同 的 含义 ， 有 的 授权 关键 字 只 用 在 特定 的 


C 代 表 创 建 。 仅 在 通配符 版 本 库 授 权时 可 以 使 用 。 用 于 指定 谁 可 
以 创建 与 通配符 匹配 的 版 本 库 。 


R、RW 和 RW+ 


R 为 只 读 。RW 为 读 写 权限 。RW+ 含 义 为 除了 具有 读 写 权限 外 ， 还 
可 以 强制 执行 非 快 进 式 推送 。 


RWC 、 RW+C 


只 有 当 授 权 指 令 中 定义 了 正则 引用 〈 正 则 表达 式 定 义 的 分 文 、 里 
程 碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 C 的 含义 是 允许 创建 和 正 
则 表达 式 匹配 的 引用 〈 分 文 或 里 程 碑 等 ) 。 加 号 (+) 的 含义 是 允许 
强制 推送 。 


RWD 、RW+D 


只 有 当 授权 指令 中 定义 了 正则 引用 〈 正 则 表达 式 定 义 的 分 文 、 里 
程 碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 D 的 含义 是 允许 删除 和 正 


则 表达 式 匹配 的 引用 (分 支 或 里 程 碑 等 ) ， 加 号 (+) 的 含义 是 允许 
强制 推送 。 


RWCD 、RW+CD 


只 有 当 授 权 指 令 中 定义 了 正则 引用 (正则 表达 式 定 义 的 分 支 、 里 
程 碑 等 ) 时 ， 才 可 以 使 用 该 授权 指令 。 其 中 C 的 含义 是 允许 创建 和 正 
则 表达 式 匹配 的 引用 〈 分 文 或 里 程 碑 等 ) ，D 的 含义 是 允许 删除 和 正 
则 表达 式 匹配 的 引用 (分 支 或 里 程 碑 等 ) ， 加 号 (+) 的 含义 是 允许 
强制 推送 。 


30.3.4 ”Gitolite 授 权 机 制 


Gitolite 的 授权 实际 分 为 两 个 阶段 ， 第 一 个 阶段 称 为 前 Git 阶 段 ， 即 
在 Git 命 令 执行 前 ， 由 SSH 连 接触 发 的 gl-auth-command 命 令 执行 的 授权 
今 查 9 包括 s 


版 本 库 的 读 。 


如 有 果 用 户 拥 有 版 本 库 《或 至 少 一 个 分 文 ) 的 下 列 权 限 之 一 : R、 


RW 或 RW+， 则 整个 版 本 库 (包含 所 有 分 支 ) 对 用 户 均 可 读 。 


实际 上 为 用 户 设置 菜 个 分 支 的 R 权 限 的 含义 并 非 其 他 分 支 不 可 
读 ， 而 是 此 分 支 不 可 写 。 之 所 以 Gitolite 对 读 授权 不 能 细 化 到 分 支 甚至 
目录 ， 只 能 粗放 地 对 整个 版 本 库 进 行 读 授 权 ， 是 因为 读 授 权 只 在 版 本 
库 授权 的 第 一 个 阶段 进行 检查 ， 而 在 此 阶段 还 获取 不 到 版 本 库 的 分 
pa 


版 本 库 的 写 。 


版 本 库 的 写 授 权 实 际 上 要 在 两 个 阶段 分 别 进行 检查 。 第 一 阶段 仅 
检查 用 户 是 否 拥 有 下 列 权 限 之 一 :， RW、RW+ 或 Cc 授权， 具有 这 些 授权 
则 通过 第 一 阶段 的 写 权 限 检 查 。 至 于 要 在 第 二 个 阶段 进行 基于 分 文 和 


路 径 的 写 操作 授权 ， 以 及 对 分 文 创建 、 删 除 和 是 否 可 强制 更 新 进行 判 
断 ， 则 参见 后 面 对 第 二 阶段 授权 过 程 的 描述 。 


版 本 库 的 创建 。 


仅 对 正则 表达 式 定义 的 通配符 版 本 库 有 效 。 即 拥有 C 授 权 的 用 户 
可 以 创建 和 对 应 正则 表达 式 匹 配 的 版 本 库 。 同 时 该 用 户 也 拥有 对 版 本 
库 的 读 写 权限 。 


Gitolite 对 授权 的 第 二 个 阶段 的 检查 ， 实 际 上 古 通 过 update 钓 子 脚 
本 进行 的 。 


因为 版 本 库 的 读 操 作 不 执行 update 钧 子 ， 所 以 读 操作 只 在 授权 的 
第 一 个 阶段 (前 Git 阶 段 ) 就 完成 了 检查 ， 授 权 的 第 二 个 阶段 对 版 本 库 
的 读 授权 无 任何 影响 。 


钩子 脚本 update 针 对 推送 操作 的 各 个 分 文 进行 逐一 检查 ， 因 此 第 
二 个 阶段 可 以 进行 针对 分 文 写 操作 的 精细 授权 。 


在 这 个 阶段 可 以 获取 到 要 更 狐 的 新 、 老 引用 的 SHA1 哈 币值， 因此 
可 以 判断 出 十 否 发 生 了 非 快 进 式 推送 、 是 否 有 新 分 支 创 建 ， 以 及 是 否 
发 生 了 分 文 的 删除 ， 因 此 可 以 针对 这 些 操作 进行 精细 的 授权 。 


基于 路 径 的 写 授 权 也 是 在 这 个 阶段 进行 的 。 


30.4 版 本 库 授 权 和 案例 


Gitolite 的 授权 非常 强大 也 非常 复兴 ， 因 此 从 版 本 库 授权 的 实际 案 
例 来 学 习 古 非常 有 效 的 方式 。 


30.4.1 对 整个 版 本 库 进行 授权 


授权 文件 如 下 : 


1 Q@admin=jiangxin 
2 @dev=dev1 dev2 badboy jiangxin 
3 @test=test1 test2 


4 
5 repo testing 
6 R=@test 

7 -=badboy 

8 RW=@dev test1 
9 RW+=@admin 


说 明 : 


用 户 test1 对 版 本 库 具 有 瑟 的 权限 。 


第 6 行 定义 了 test1 所 属 的 用 户 组 @test 具 有 只 读 权 限 。 第 8 行 定 义 了 
test1 用 户 具有 读 写 权限 。Gitolite 的 实现 是 对 读 权 限 和 写 权 限 分 别 进行 
判断 并 汇总 (并 集 ) ， 从 而 test1 用 户 具 有 读 写 权限 。 


用 户 jiangxin 对 版 本 库 具 有 写 的 权限 ， 并 能 够 强制 推送 。 


第 9 行 授权 指令 中 加 号 (+) 的 含义 是 允许 强制 推送 。 


禁用 指令 ， 让 用 户 badboy 只 对 版 本 库 具 有 读 操 作 的 权限 。 


第 7 行 的 指令 以 减 号 (-) 开始 ， 是 一 条 禁用 指令 。 茜 用 指令 只 在 
授权 的 第 二 阶段 起 作用 ， 即 只 对 写 操作 起 作用 ， 不 会 对 badboy 用 户 的 
读 权限 施加 影响 。 

在 第 8 行 的 指令 中 ，badboy 所 在 的 @dev 组 拥有 读 写 权限 。 但 禁用 
规则 会 对 写 操 作 起 作用 ， 导 致 badboy 只 有 读 操 作 权限 ， 而 没有 写 操 
作 。 


30.4.2 ”通配符 版 本 库 的 授权 


授权 文件 贡 下 : 


1 @administrators=jiangxin admin 
2 Q@dev=dev1 dev2 badboy 

3 Qtest=test1 test2 

4 

5 repo sandbox/.+$ 

6 C=@administrators 

7 R=@test 

8 -=badboy 

9 RW=@dev test1 


这 个 授权 文件 的 版 本 库 名 称 中 使 用 了 正则 表达 式 ， 匹 配 在 sandbox 
下 的 任意 版 本 库 。 


正则 表达 式 末 尾 的 $ 有 着 特殊 的 侣 义 ， 代 表 匹 配 字符 串 的 结尾 ， 明 
确 告 诉 Gitolite 这 个 版 本 库 是 通配符 版 本 库 。 因 为 加 号 + 既 可 以 作为 普 
通 字 符 出 现在 版 本 库 的 命名 中 ， 又 可 以 作为 正则 表达 式 中 特殊 含义 的 


字符 ， 如 果 Gitolite 将 授权 文件 中 的 通配符 版 本 库 误 判 为 普通 版 本 库 ， 
束 会 目 动 在 服务 凑 端 创建 该 版 本 库 ， 这 可 不 是 管理 员 和 希望 发 生 的 。 


我 修改 了 Gitolite 的 代码 ， 能 正确 判断 部 分 正则 表达 式 ， 但 是 最 好 
还 是 对 简单 的 正则 表达 式 添 加 ^ 作 为 前 绥 或 $ 作 为 后 缀 ， 以 避免 误 判 。 


正则 表达 式 定义 的 通配符 版 本 库 不 会 目 动 创建 ， 需 要 管理 员 手 动 
创建 。 


Gitolite 原 来 对 通配符 版 本 库 的 实现 是 克隆 即 创建 ， 但 是 这 样 很 容 
易 因为 录入 错误 而 导致 错误 的 版 本 库 被 意外 创建 。 我 改进 的 Gitolite 需 
要 通过 推送 来 创建 版 本 库 。 


下 面 的 示例 通过 推送 操作 (以 admin 用 户 身份 ， 远 程 创建 版 本 库 


Sandbox/repos1.git。 


$git push gitolite [1] :sandbox/repos1i.git master 


创建 完毕 后 对 各 个 用 户 的 权限 进行 测试 会 发 现 : 


用 户 admin 对 版 本 库 具 有 写 的 权限 。 


这 并 不 是 因为 第 6 行 的 授权 指令 为 @administrators 授 予 了 C 的 权 
限 。 而 是 因为 该 版 本 库 是 由 admin 用 户 创建 的 ， 创 建 者 具有 对 版 本 库 完 
全 的 读 写 权限 。 


服务 如 端 该 版 本 库 目 孙 目 动 生 成 的 gl-creator 文 件 记 录 了 创建 者 的 
ID 为 admin 。 


用 户 jiangxin 对 版 本 库 没 有 读 写 权限 。 


虽然 用 户 jiangxin 和 用 户 admin 一 样 都 可 以 在 sandbox/ 下 创建 版 本 
库 ， 但 是 由 于 sandboxmreposl.git 已 经 存在 并 且 不 是 jiangxin 用 户 创建 
的 ， 所 以 jiangxin 用 户 没有 任何 权限 ， 不 能 读 写 。 


和 之 前 的 例子 相同 的 是 : 


〇 用 户 test1 对 版 本 库 具 有 写 的 权限 。 


O 蔡 用 指令 让 用 户 badboy 对 版 本 库 只 有 具有 读 操 作 的 权限 。 


版 本 库 的 创建 者 还 可 以 使 用 setperms 命 令 为 版 本 库 添 加 授权 。 
体 用 法 参见 下 面 的 示例 。 


[1] gitolite 是 安装 Gitolite 过 程 中 创建 的 主机 别名 ， 是 以 admin 用 户 身 份 
连接 Git 服 务 硕 


30.4.3 用户 目 己 的 版 本 库 空 间 


授权 文件 贡 下 : 


1 Q@administrators=jiangxin admin 
2 

3 repo users/CREATOR/.+$ 

4 C=@all 

5 R=@administrators 


说 明 : 


第 5 条 指令 ， 设 置 管理 员 组 对 任何 用 户 在 users/ 目 未 下 创建 的 版 本 
库 都 有 只 读 权 限 。 第 4 条 指令 ,设置 用 户 可 以 在 目 己 的 名 字 空 间 
(usrs/<userid>/) 下 ， 上 自己 创建 版 本 库 。 例 如 下 面 就 是 用 户 dev1 在 
服务 硕 端 目 己 的 名 字 罕 间 下 创建 版 本 库 。 


$git push devi-server [1] :USers/devi/repos1i.git master 


用 户 dev1 可 以 通过 ssh 连 接 服务 絮 ， 使 用 setperms 命 令 为 目 己 的 版 
本 库 进行 二 次 授权 。 当 setperms 指 令 执 行 时 ， 会 局 用 编辑 界面 ， 授 权 
日 令 录入 完毕 后 ， 输 入 AD (Ctrl+D) 结束 编辑 。 如 下 所 示 : 
$ssh devi-server setperms users/devi/repos1.git 
R=dev2 


RW=j iangxin 
AD 


在 执行 setperms 进 行 授权 时 ， 也 可 以 预先 将 授权 写 入 文件 ， 再 使 
用 输入 重 定 癌 ， 通 过 setperms 命 令 加 载 ， 如 下 所 示 。 


$cat >perms< <EOF 

R=dev2 

RW=j iangxin 

EOF 

$ssh devi@server setperms<perms 


用 户 可 以 使 用 getperms 碍 看 为 目 己 的 版 本 库 建 立 的 授权 。 


$ssh devi@server getperms users/devi/repos1.git 
R=dev2 
RW=j iangxin 


[1] dev1-server 是 别名 主机 ， 是 用 dev1 用 户 的 公 钥 访问 server 。 


30.4.4 对 引用 的 授权 : 传统 模式 


传统 的 引用 授权 指 的 是 授权 指令 中 不 包含 RWC、RWD、RWCD、 
RW+C、RW+D、RW+CD 授 权 关 键 字 ， 只 采用 RW 和 RW+ 的 传统 授权 
关键 字 。 


在 只 使 用 传统 的 授权 关键 字 的 情况 下 ， 有 如 下 注意 事项 : 


非 快 进 式 推送 必须 拥有 + 的 授权 。 


创建 引用 必须 拥有 W 的 授权 。 


删除 引用 必须 拥有 + 的 授权 。 


如 采 没 有 在 授权 指令 中 提供 引用 相关 的 参数 ， 相 当 于 提供 refs/.* 作 
为 引用 的 参数 ， 意 味 着 对 所 有 引用 均 有 效 。 


授权 文件 : 


1 Q@administrators=jiangxin admin 

2 Q@dev=dev1 dev2 badboy 

3 

4 repo test/repol 

5 RW+=@administrators 

6 RW master refs/heads/feature/=@dev 
7 R=@test 


说 明 : 


第 5 行 ， 对 于 版 本 库 tesVrepo1， 管 理 员 组 用 户 jiangxin 和 admin 可 以 
任意 创建 和 删除 引用 ， 并 且 可 以 强制 推送 。 


第 6 行 的 规则 看 似 是 只 对 master 和 refs/heads/feature/* 的 引用 授权 ， 
实际 上 @dev 可 以 读 取 所 有 名 字 择 间 的 引用 。 这 是 因为 恋 取 操作 无 法 获 
得 引用 相关 的 内 容 。 即 用 户 组 @dev 的 用 户 只 能 对 master 分 支 ， 以 及 以 
feature/ 开 头 的 分 文 进行 写 操作 ， 但 不 能 强制 推送 和 删除 。 至 于 其 他 分 
文 和 里 程 碑 ， 则 只 能 读 不 能 写 。 


至 于 用 户 组 @test 的 用 户 ， 因 为 使 用 了 R 授 权 指 令 ， 所 以 不 涉及 分 
文 的 写 授权 。 


30.4.5 ”对 引用 的 授权 :扩展 模式 


扩展 模式 的 引用 授权 ， 指 的 是 该 版 本 库 的 授权 指令 出 现 了 下 列 授 
权 关 键 字 中 的 一 个 或 多 个 : RWC 、RWD 、RWCD 、RW+C、RW+D、 
RW+CD。 则 Gitolite 对 授权 采用 新 的 判定 方式 。 


非 快 进 式 推送 必须 拥有 + 的 授权 。 
创建 引用 必须 拥有 C 的 授权 。 
删除 引用 必须 拥有 D 的 授权 。 


即 引用 的 创建 和 删除 使 用 了 单独 的 授权 关键 字 ， 和 写 权 限 和 强制 
推送 权限 分 开 。 下 面 是 一 个 采用 扩展 授权 关键 字 的 授权 文件 : 


repo test/repo2 
RW+C=@administrators 
RW+=@dev 

RW=@test 

repo test/repo3 
RW+CD=@administrators 
RW+C=@dev 

RW 

=Q@test 


通过 上 面 的 配置 文件 ， 对 于 版 本 库 testrepo2.git 具 有 如 下 的 授权 : 


用 户 组 @administrators 中 的 用 户 ， 具 有 创建 和 删除 引用 的 权限 ， 
并 且 能 够 强制 推送 。 


用 户 组 @dev 中 的 用 户 ， 不 能 创建 引用 ， 但 可 以 删除 引用 ， 并 且 可 
以 强制 推送 。 


用 户 组 @test 中 的 用 户 ， 可 以 推送 到 任何 引用 ， 但 是 不 能 创建 引 
用 ， 不 能 删除 引用 ， 也 不 能 强制 推送 。 


通过 上 面 的 配置 文件 ， 对 于 版 本 库 testrepo3.git 具 有 如 下 的 授权 : 


用 户 组 @administrators 中 的 用 户 ， 具 有 创建 和 删除 引用 的 权限 ， 
并 且 能 够 强制 推送 。 


用 户 组 @dev 中 的 用 户 ， 可 以 创建 引用 ， 并 能 够 强制 推送 ， 但 不 能 
删除 引用 。 


用 户 组 @test 中 的 用 户 ， 可 以 推送 到 任何 引用 ， 但 是 不 能 创建 引 
用 ， 不 能 删除 引用 ， 也 不 能 强制 推送 。 


30.4.6 ”对 3 引用 的 授权 : 禁用 规则 的 使 用 


人 


1 repo testing 
12 RW refs/tags/v[0-9]=jiangxin 


13 -refs/tags/v[0-9]=devi dev2@others 
14 RW refs/tags/=jiangxin dev1 dev2Q@others 


说 明 : 


用 户 jiangxin 可 以 写 任何 里 程 碑 ， 包 括 以 v 加 上 数字 开头 的 里 程 


用 户 dev1、dev2 和 @others 组 ， 只 能 写 除 了 以 v 加 上 数字 开头 之 外 
的 其 他 里 程 碑 。 


其 中 以 -开头 的 授权 指令 建立 栓 用 规则 。 禁 用 规则 只 在 授权 的 第 二 
阶段 有 效 ， 因 此 不 能 限制 用 户 的 读 取 权 限 ! 


30.47 用 户 分 文 
和 创建 用 户 空间 (使 用 了 CREATOR 关 键 字 ) 的 版 本 库 类 似 ， 还 
可 以 在 一 个 版 本 库 内 允 


许 管 理 自己 名 字 空 间 (USER 关 键 字 ) 下 的 分 文 。 在 正则 引用 的 
参数 中 出 现 的 USER 关 键 字 会 被 奉 换 为 用 户 的 ID 。 


授权 文件 : 


repo test/repo4 
RW+CD=@administrators 

RW+CD refs/personal/USER/=@all 
RW+master=@dev 


说 明 : 


用 户 组 @administrators 中 的 用 户 ， 对 所 有 引用 具有 创建 和 删除 的 
权限 ， 并 且 能 强制 推送 。 


所 有 用 户 都 可 以 在 refs/personal/<userid>/ (自己 的 名 字 空 间 ) 下 
创建 和 删除 引用 。 但 是 不 能 修改 其 他 人 的 引用 。 


用 户 组 @dev 中 的 用 户 对 master 分 文具 有 读 写 和 强制 更 新 的 权限 ， 
但 是 不 能 删除 。 


30.4.8 ”对 路 径 的 写 授权 


Gitolite 也 实现 了 对 路 径 的 写 操作 的 精细 授权 ， 并 且 非 和 党 巧妙 的 
征 : 在 实现 上 增加 的 代码 可 以 忽略 不 计 。 这 有 是 因为 Gitolite 把 路 径 当 作 
征 特 殊 格式 的 引用 的 授权 。 


在 授权 文件 中 ， 如 果 一 个 版 本 库 的 授权 指令 中 的 正则 引用 字段 出 
现 了 以 NAME/ 开 头 的 引用 ， 则 表明 该 授权 指令 是 针对 路 径 进 行 的 写 授 
权 ， 并 且 该 版 本 库 要 进行 基于 路 径 的 写 授权 判断 。 


示例 : 


1 repo foo 
2 RW=@junior_devs@senior_devs 
3 


4 RW NAME/=@senior_devs 


5 -NAME/Makefile=@junior_devs 
6 RW NAME/=@junior_devs 


说 明 : 


第 2 行 ， 初 级 程序 员 @junior_devs 和 高 级 程序 员 @senior_devs 可 以 
对 版 本 库 foo 进 行 读 写 操作 。 


第 4 行 ， 设 定 高 级 程序 员 @senior_devs 对 所 有 文件 (NAME/) 进行 
写 操 作 。 


第 5 行 和 人 第 6 行 ， 设 定 初 级 程序 员 @junior_devs 对 除了 根 目录 的 
Makefile 文 件 外 的 其 他 文件 具有 写 权 限 。 


30.5 创建 新 版 本 库 


Gitolite 维 护 的 版 本 库 默 认 位 于 安装 用 户主 目录 下 的 repositories 目 
录 中 ， 即 如 果 安 装 用 户 为 git， 则 版 本 库 都 创建 在 /home/git/repositories 
目录 之 下 。 可 以 通过 配置 文件 .gitolite.rc 修 改 默 认 的 版 本 库 的 根 路 径 。 


$REPO_BASE="repositories"; 


有 多 种 创建 版 本 库 的 方式 。 一 种 是 在 授权 文件 中 用 repo 指 令 设置 
版 本 库 (未 使 用 正则 表达 式 的 版 本 库 ) 的 授权 ， 当 对 gitolite-admin 版 
本 库 执行 git push 操 作 时 ， 目 动 在 服务 端 创建 新 的 版 本 库 。 另 外 一 种 方 
式 是 在 授权 文件 中 用 正则 表达 式 定 义 的 通配符 版 本 库 ， 不 会 即时 创建 
(也 不 可 能 被 创建 ) ， 而 是 被 授权 的 用 户 在 远程 创建 后 推送 到 服务 器 
上 完成 创建 。 


注意 ;在 授权 文件 中 出 现 的 版 本 库 名 称 不 要 市 .git 后 级， 在 创建 版 
本 库 过 程 中 会 目 动 在 版 本 库 后 面 退 加 .git 后 缀 。 


30.5.1 在 配置 文件 中 出 现 的 版 本 库 ， 即 时 生成 


尝试 在 授权 文件 conf/gitolite.conf 中 加 入 一 段 新 的 版 本 库 授 权 指 
令 ， 而 这 个 版 本 库 尚 不 存在 。 新 添加 到 授权 文件 中 的 内 容 为 : 


repo testing2 
RW+=@all 


然后 将 授权 文件 的 修改 提交 并 推送 到 服务 器 ， 会 看 到 授权 文件 中 
添加 新 授权 的 版 本 库 testing2 被 自动 创建 。 


$git push 

Counting objects:7,done. 

Delta compression using up to 2 threads. 

Compressing objects:100%(3/3),done. 

Writing objects:100%(4/4),375 bytes, done. 

Total 4(delta 1),reused 0O(delta 0) 

remote:Already on 'master' 

remote:creating testing2... 

remote:Initialized empty Git repository 
in/home/git/repositories/testing2.git/ 

To gitadmin.bj:gitolite-admin.git 

278e54b..b6fO5c1 master->master 


注意 其 中 带 remote 标 识 的 输出 ， 可 以 看 到 版 本 库 testing2.git 被 自动 
初始 化 了 。 


此 外 使 用 版 本 库 组 的 语法 ( 即 用 @ 创 建 的 组 ， 用 作 版 本 库 ) ， 也 
会 被 目 动 创建 。 例 如 下 面 的 授权 文件 片段 设 定 了 一 个 包含 两 个 版 本 库 
的 组 @testing， 当 将 新 配置 文件 推送 到 服务 器 上 时 ， 会 目 动 创建 
testing3.git 和 testing4.git 。 

Qtesting=testing3 testing4 


repoQ@testing 
RW+=@all 


还 有 一 种 版 本 库 语 法 ， 是 用 正则 表达 式 定 义 的 版 本 库 ， 这 类 版 本 
库 因 为 所 指 的 版 本 库 并 不 确定 ， 因 此 不 可 能 目 动 创建 。 


30.5.2 ”通配符 版 本 库 ， 管 理 员 通过 推送 创建 


通配符 版 本 库 是 用 正则 表达 式 语 法 定义 的 版 本 库 ， 所 指 的 并 非 某 
一 个 版 本 库 而 是 和 名 称 相符 的 一 组 版 本 库 。 要 想 使 用 通配符 版 本 库 ， 
需要 在 服务 器 端 Gitolite 的 安装 用 户 (如 git) 主 目录 下 ， 修 改 配置 文 
件 .gitolite.rc， 使 其 包含 如 下 配置 : 


$GL_WILDREPOS=1; 


使 用 通配符 版 本 库 ， 可 以 对 一 组 版 本 库 进 行 授权 ， 非 党 有 效 。 但 
古 版 本 库 的 创建 则 不 像 前 面 介绍 的 那样 ， 不 会 在 授权 文件 推送 到 服务 
器 时 创建 ， 而 是 由 拥有 版 本 库 创 建 授权 (C) 的 用 户 手工 进行 创建 。 


对 于 用 通配符 设置 的 版 本 库 ， 用 C 指 令 指定 能 够 创建 此 版 本 库 的 
管理 员 (拥有 创建 版 本 库 的 授权 ) 。 例 如 : 
repo OSssxp/ .+ 
C=]liangxin 
RW=dev1 dev2 
管理 员 jiangxin 可 以 创建 路 径 符 合 正 则 表达 式 "ossxp/.+" 的 版 本 库 ， 
用 户 dev1 和 dev2 对 版 本 库 具 有 读 写 (但 是 没有 强制 更 新 ) 权限 。 


使 用 该 方法 创建 版 本 库 后 ， 创 建 者 的 uid 将 被 记录 在 版 本 库 目 孙 下 
的 gl-creator 文 件 中 。 该 账号 具有 对 该 版 本 库 最 高 的 权限 。 该 通配符 版 
本 库 的 授权 指令 中 如 果 出 现 CREAITOR 将 被 创建 者 的 uid 硅 换 。 


本 地 建 库 。 


$mkdir somerepo 

$cd somerepo 

$git init 

$git commit--allow-empty 


使 用 git remote 指 令 设 置 远程 版 本 库 。 
$git remote add origin jiangxin-server [1] :OSSxp/somerepo.git 


运行 git push 完 成 在 服务 器 剖 版 本 库 的 创建 。 


$git push origin master 


Gitolite 的 原始 实现 是 通配符 版 本 库 的 管理 员 在 对 不 存在 的 版 本 库 
执行 done 操 作 时 目 动 创建 的 。 但 古 我 认为 这 不 是 一 个 好 的 实践 ， 经 芝 
会 因为 在 克隆 时 把 URL 写 错 ， 从 而 导致 在 服务 右 端 创建 垃圾 版 本 库 。 
因此 我 重新 改 迁 了 gitolite 通 配 符 版 本 库 创建 的 实现 方法 ， 改 为 在 对 版 
本 库 进 行 推送 的 时 候 进 行 创建 ， 而 clone 一 个 不 存在 的 版 本 库 会 报错 退 
证 六 


[1] jiangxin-server 是 设置 的 别名 主机 ， 有 是 以 jiangxin 用 户 的 公 钥 访问 


server 服 务 器 。 


30.5.3 直接 在 服务 硕 端 创建 


当 版 本 库 的 数量 很 多 的 时 候 ， 在 服务 器 端 直接 通过 git init 命 令 创 
建 ， 或 者 通过 复制 创建 可 能 会 更 方便 。 但 是 要 注意 ， 在 服务 人 右 端 手工 
创建 的 版 本 库 和 Gitolite 创 建 的 版 本 库 最 大 的 不 同 在 于 钓 子 脚本 。 如 果 
不 能 为 手工 创建 的 版 本 库 正确 设 定 版 本 库 的 钧 子 ， 会 导致 失去 Gitolite 
特有 的 一 些 功能 ， 例 如 失去 分 文 授 权 的 功能 。 


一 个 由 Gitolite 创 建 的 版 本 库 ，hooks 目 孙 下 有 三 个 钩子 脚本 实际 上 
链接 到 gitolite 安 泌 目 隶 下 的 相应 的 脚本 文件 中 : 


gitolite-hooked->/home/git/.gitolite/hooks/common/gitolite- 
hooked 

post-receive.mirrorpush->/home/git/.gitolite/hooks/common/post- 
receive.mirrorpush 

update->/home/git/.gitolite/hooks/common/update 


那么 手工 在 服务 器 上 创建 的 版 本 库 ， 有 没有 目 动 更 新 钧 子 脚本 的 
方法 呢 ? 


第 一 个 方法 是 修改 Git 模 板 中 ， 在 创建 版 本 库 时 自动 创建 初始 的 钧 
子 脚本 。 再 有 就 是 重新 执行 一 遍 Gitolite 的 安装 ， 会 自动 更 新 版 本 库 的 
钩子 脚本 。 安 三 过 程 一 路 按 回 车 即 可 。 


$cd gitolite/src 
$./gl-easy-install] git server admin 


除了 要 注意 钩子 脚本 以 外 ， 还 要 确 保 服 务 众 端 版 本 库 目 孙 的 权限 
和 属 主 。 


[1] 参见 第 8 篇 第 41 章 “41.2.2 Git 模 板 ” 的 相关 内 容 。 


30.6 ”对 Gitolite 的 改进 


笔者 对 Gitolite 进 行 扩 展 和 改进 ， 涉 及 的 内 容 主 要 包括 : 

通配符 版 本 库 的 创建 方式 和 授权 。 

原来 的 实现 是 克隆 即 创建 (克隆 者 需要 被 授予 C 的 权限 ) 。 同 时 
还 要 通过 男 外 的 授权 语句 为 用 户 设 置 RW 权限 ， 否 则 创建 者 没有 读 和 
写 的 权限 。 

新 的 实现 是 通过 推送 创建 版 本 库 (推送 者 需要 被 授予 C 权 限 ) 。 
不 必 再 为 创建 者 赋予 RW 等 权限 ， 创 建 者 目 动 具有 对 版 本 库 最 高 的 授 
模 * 


避免 通配符 版 本 库 的 误 判 。 


大 将 通配符 版 本 库 误 判 为 普通 版 本 库 名 称 ， 会 导致 在 服务 器 端 创 
建 错误 的 版 本 库 。 新 的 设计 可 以 在 通配符 版 本 库 的 正则 表达 式 之 前 添 
加 人 或 之 后 添加 $ 字 符 避 免 误 判 。 


改变 默认 配置 。 


锥 认 安 痛 即 文 持 通配符 版 本 库 。 


版 本 库 重 定 同 。 


Gitosis 的 一 个 很 重要 的 功能 一 一 版 本 库 名 称 重 定 同 ， 没 有 在 
Gitolite 中 实现 。 我 为 Gitolite 增 加 了 这 个 功能 。 


在 Git 服 务 器 架设 的 初期 ,版 本 库 的 命名 可 能 非常 随意 ， 例 如 ， 
redmine 的 版 本 库 直 接 放 在 根 下 : redmine-0.9.x.git、redmine- 
1.0.x.git.….….. 随 着 redmine 项 目 越 来 越 复 杂 ， 可 能 就 需 要 将 其 放 在 子 目 
录 下 进行 管理 ， 例 如 放 到 ossxp/redmine/ 目 录 下 。 只 需要 在 Gitolite 的 授 
权 文 件 中 添加 下 面 一 行 map 语 句 ， 就 可 以 实现 版 本 库 名 称 的 重 定向 。 
使 用 旧地 址 的 用 户 不 必 重 新 检 出 ， 可 以 继续 使 用 。 


map(redmine.*)=ossxp/redmine/$1 


30.7 ”Gitolite 功 能 拓展 


30.7.1 版 本 库 镜像 


1. 版 本 库 镜 像 的 用 途 和 原理 


Git 版 本 库 控制 系统 往往 并 不 需要 设计 特别 的 容 灾 备 份 ， 因 为 每 一 
个 Git 用 户 融 是 一 个 备份 。 但 是 下 面 的 情况 ， 束 很 有 必要 考虑 容 灾 了 。 


Git 版 本 库 的 使 用 者 很 少 (每 个 库 可 能 只 有 一 个 用 户 ) 。 


版 本 库 克隆 只 限制 在 办 公 区 并 且 服 务 器 也 在 办 公 区 内 (所 有 鸡蛋 
都 在 一 个 篮子 里 )。 


Git 版 本 库 采 用 集中 式 的 应 用 模型 ， 需 要 建立 双 机 热 备 〈 以 便 在 故 
障 出 现时 ， 实 现 快速 的 服务 器 切换 ) 。 


Gitolite 提 供 了 服务 器 则 版 本 库 同步 的 设置 。 原 理 古 : 


主 服务 器 通 过 配置 文件 ~/.gitolite.rc 中 的 变量 $8SENV{GL_SLAVES} 
设置 锐 像 服务 絮 的 地 址 。 


从 服务 器 通过 配置 文件 ~/.gitolite.rc 中 的 变量 $GL_SLAVE_MODE 
设置 为 从 服务 器 模式 。 


从 主 服务 器 端 运行 脚本 gl-mirrorsync 可 以 实现 批量 的 版 本 库 镜 
像 。 


主 服务 絮 的 每 一 个 版 本 库 都 配置 post-receive 钧 子 ， 一旦 有 提交 ， 
即时 同步 到 镜像 版 本 库 。 

2. 版 本 库 镜 像 的 实现 方法 

在 多 个 服务 器 之 间 设 置 Git 库 镜像 的 方法 是 : 

(1) 每 个 服务 器 都 要 安装 Gitolite 软 件 ， 而 且 要 启用 post-receive 钓 
子 。 默 认 的 钧 子 在 源 代码 的 hooks/common 目 录 下 ， 和 名 称 为 post- 


receive.mirrorpush， 要 将 其 改名 为 post-receive。 否 则 版 本 麻 的 post- 
receive 脚 本 不 能 生效 。 


(2) 主 服务 器 配置 到 从 服务 器 的 公 钥 认证 ， 配 置 使 用 特殊 的 
shell:gl-mirror-shell。 这 是 因为 主 服 务 硕 在 回 从 服务 器 同步 版 本 库 的 时 
候 ， 如 果 没 有 创建 从 服务 器 上 相应 的 版 本 库 ， 则 需要 直接 通过 SSH 登 
录 到 从 服务 器 ， 执 行 创建 命令 创建 版 本 库 。 因 此 需要 通过 一 个 特殊 的 
shell， 能 够 同时 支持 Gitolite 的 授权 访问 及 shell 环 境 。 这 个 特殊 的 shell 
就 是 gl-mirror-shell。 而 且 这 个 shell 可 以 通过 特殊 的 环境 变量 绕 过 服务 
器 的 权限 检查 ， 避 免 因为 授权 问题 而 导致 同步 失败 。 


实际 应 用 中 ， 不 光 主 服务 器 ， 每 个 服务 名 都 要 进行 类 似 设置 ， 目 
的 是 主 从 服务 器 可 能 相互 切换 。 注 意 : 在 Gitolite 不 同 的 安装 模式 下 ， 
8 由 -mirrorshell 的 安 效 位 置 可 能 不 同 。 


下 面 的 命令 用 于 更 改 服务 器 端 Gitolite 安 装 用 户 的 
~/.sshyauthorized_keys 配 置 文件 ， 以 便 使 用 特定 公 钥 的 其 他 服务 器 在 
访问 本 服务 器 时 使 用 这 个 特殊 的 shel。 假 设 在 服务 器 foo 上 ， 配 置 服务 
器 bar 和 baz 使 用 特殊 的 shell， 而 来 自 这 两 个 服务 器 的 连接 分 别 使 用 
barpub 和 baz.pub 两 个 公 钥 文件 。 


对 于 以 客户 端 安装 方式 部 署 的 Gitolite， 可 以 通过 下 面 的 方法 确定 
和 -mirror-shell 的 位 置 ， 然 后 修改 ~/.ssh/authorized_keys 文 件 。 


# 在 服务 器 foo 上 执行 : 

$export GL ADMINDIR=cd$HOME; perl-e 'do ".gitolite.rc"; 
print$GL_ADMINDIR 

$cat bar.pub baz.pub| 

sed-e 's,^,command=" '$GL ADMINDIR'/src/gl-mirror-shell",'>> 

~/.ssh/authorized_keys 


一 


对 于 以 服务 器 端 安装 方式 部 署 的 Gitolite， 可 以 在 路 径 中 找到 gl- 
mirror-shell ， 进 而 设置 ~/.ssPyauthorized_keys 文 件 。 


# 在 服务 器 foo 上 执行 : 

$cat bar.pub baz.pub| 

sed-e 's,^,command=" ' $(which gl-mirror-shell) '",'>> 
~/.ssh/authorized_keys 


(3) 在 foo 服 务 器 上 设置 完毕 后 ， 可 以 从 服务 器 bar 或 baz 上 远程 执 
行 下 列 命令 进行 测试 : 


执行 命令 后 退出 。 
$ssh git@foo pwd 
进入 shell。 


$ssh git@foo bash-i 


(4) 在 从 服务 器 上 设置 配置 文件 ~/.gitolite.rc 。 


进行 如 下 设置 后 ， 将 不 允许 用 户 直 接 推送 到 从 服务 器 。 但 是 主 服 
妖 仍 然 可 以 推送 到 从 服务 器 ， 是 因为 主 服 务 器 版 本 库 在 推送 到 从 服 
右 时 ， 使 用 了 特殊 的 环境 变量 ， 能 够 跳 过 从 服务 右 版 本 库 的 update 
脚本 。 


务 
务 


$GL_SLAVE_MODE=1 


(5) 在 主 服务 器 上 设置 配置 文件 ~/.gitolite.rc 。 


需要 配置 到 从 服务 器 的 SSH 连 接 ， 可 以 设置 多 个 ， 用 空格 分 隔 。 
注意 使 用 单 引号 ， 以 避免 @ 字 符 被 Penl 当 作 数 组 解析 。 


$ENV{GL_SLAVES}="'gitolite@bar gitolite@baz'; 


〈6) 在 主 服务 如 端 执行 gl-mirror-sync 进 行 一 次 完整 的 数据 同步 。 


需要 以 Gitolite 安 装 用 户 的 身份 (如 git) 执行 。 例 如 在 服务 器 foo 上 
执行 到 从 服务 器 bar 的 同步 。 


$gl1-mirror-sync gitolite@bar 


(7) 之 后 ， 用 户 每 次 癌 主 版 本 库 同步 ， 都 会 通过 版 本 库 的 post- 
receive 钧 子 即时 同步 到 从 版 本 库 。 


当主 版 本 库 出 现 故 障 时 ， 束 需要 把 从 服务 圳 切换 为 主 服 务 右 模 
式 ， 这 就 需要 进行 主 从 版 本 库 的 切换 设置 。 切 换 非 常 简单 ， 束 是 修改 
~-/.gitolite.rc 配 置 文件 ， 修 改 $4GL_SLAVE_MODE 设 置 : 主 服务 器 设置 
为 0， 从 服务 器 设置 为 1。 注 意 在 主 服 务 器 恢复 之 前 ， 要 修改 主 服务 器 
的 配置 使 之 降级 为 从 服务 器 ， 否 则 主 服 务 器 恢复 工作 后 会 造成 同时 存 
在 多 个 主 服务 器 ， 从 而 导致 数据 的 相互 覆盖 。 


30.7.2 ”Gitweb 和 Git daemon 支 持 


Gitolite 和 git-daemon 的 整合 很 简单 ， 束 是 由 Gitolite 创 建 的 版 本 库 
会 在 版 本 库 目 录 中 创建 一 个 空 文件 git-daemon-export-ok 。 


Gitolite 和 Gitweb 的 整合 则 提供 了 两 个 方面 的 内 容 。 一 个 是 可 以 设 
置 版 本 库 的 描述 信息 ， 用 于 在 Gitweb 的 项 目 列表 页 面 中 显示 。 另 外 一 
个 是 目 动 生成 项 目的 列表 文件 供 Gitweb 参 考 ， 避 免 Gitweb 使 用 低 效 率 
的 目录 递归 搜索 查找 Git 版 本 库 列表 。 


可 以 在 授权 文件 中 设 定 版 本 库 的 摘 述 信息 ， 并 在 gitolite-admin 管 
理 库 更 新 时 创建 到 版 本 库 的 description 文 件 中 。 


reponame="one line of description" 
reponame"owner name"="one line of description" 


第 1 行 ， 为 名 为 reponame 的 版 本 库 设 定 描述 
第 2 行 ， 同 时 设 定 版 本 库 的 属 主 名 称 ， 以 及 一 行 版 本 库 描述 。 


对 于 通配符 版 本 库 ， 使 用 这 种 方法 则 很 不 现实 。Gitolite 提 供 了 
SSH 子 命令 供 版 本 库 的 创建 者 使 用 。 


$ssh git@server setdesc path/to/repos.git 
$ssh git@server getdesc path/to/repos.git 


第 一 条 指令 用 于 设置 版 本 库 的 描述 信息 。 


第 二 条 指令 显示 版 本 库 的 描述 信息 。 


至 于 生成 Gitweb 所 用 的 项 目 列表 文件 ， 默 认 创 建 在 用 户主 目录 下 
的 projects.list 文 件 中 。 对 于 所 有 局 用 Gitweb 的 [repo] 小 和 所 设 定 的 版 本 
库 ， 以 及 通过 版 本 库 描 述 隐 式 声 明 的 版 本 库 都 会 加 入 到 版 本 库 列 表 
中 o 


30.7.3 ”其 他 功能 拓展 和 参考 


Gitolite 源 码 的 doc 目 录 包 含 用 markdown 标 记 语言 编写 的 手册 ， 可 
以 直接 在 Github 上 查看 。 也 可 以 使 用 markdown 的 文档 编辑 工具 将 .mkd 
文档 转换 为 html 文 档 。 转 换 工 具 很 多 ， 有 rdiscount、Bluefeather、 
Maruku、BlueCloth2， 等 等 。 


这 上 坚 参 考 文档 中 ， 用 户 可 以 发 现 Gitolite 包 含 的 更 多 的 小 功能 好 
秘籍 ， 包 括 : 


版 本 库 设 置 。 
授权 文件 通过 git config 指 令 为 版 本 库 进 行 附 加 的 设置 。 例 如 : 


repo gitolite 

config hooks.mailinglist=gitolite-commits@example.tld config 
hooks.emailprefix="[gitolite]" 

config foo.bar="" 

config foo.baz= 


多 级 管理 员 授 权 。 


可 以 为 不 同 的 版 本 库 设 定 管理 员 ， 探 作 gitolite-admin 库 的 部 分 授 
权 文 件 。 具 体 参 考 : doc/5-delegation.mkd 。 


目 定义 钩子 脚本 。 


因为 Gitolite 占 用 了 几 个 钩子 脚本 ， 如 采 需 要 对 同名 钩子 进行 扩 
展 ，Gitolite 提 供 了 级 联 的 钩子 脚本 ， 将 定制 放 在 级 联 的 钩子 脚本 里 。 


例如 : 通过 目 定 义 gitolite-admin 的 postrupdate.secondary 脚 本 ， 以 
实现 无 须 登 隶 服务 右 即 可 更 改 .gitolite.rc 文 件 。 有 具体 参考 : doc/shell- 


games.mkd ° 


关于 钩子 脚本 的 创建 和 维护 ， 有 具体 参考 : doc/hook- 


propagation.mkd ° 


管理 员 目 定义 命令 。 


通过 设置 配置 文件 中 的 $GL_ADC_PATH 变 量 ， 在 远程 执行 该 目录 
下 的 可 执行 脚本 ， 如 : rmrepo。 


具体 参考 : docadmin-defned-commands.mkd 。 


创建 匿名 的 SSH 认 证 。 


允许 匿名 用 户 访问 Gitolite 提 供 的 Git 服 务 。 即 建立 一 个 和 Gitolite 服 


务 器 端 账号 同 ID 同 主 目录 的 用 户 ， 设 置 其 的 特定 shell， 并 且 允 许 口 令 


具体 参考 : doc/mob-branches.mkd 。 


可 以 通过 名 为 @all 的 版 本 库 进 行 全 局 的 授权 。 


但 是 不 能 在 @all 版 本 库 中 对 @all 用 户 组 进行 授权 。 


版 本 库 或 用 户 非常 之 多 ( 几 千 个 ) 的 时 候 ， 需 要 使 用 大 配置 文件 
模式 。 


因为 Gitolite 的 授权 文件 要 先 编译 才能 生效 ， 而 编译 文件 的 大 小 是 
和 用 户 及 版 本 库 数 量 的 乘积 成 正比 的 。 选 择 大 配置 文件 模式 则 不 对 用 
户 组 和 版 本 库 组 进行 扩展 。 


具体 参考 : doc/big-config.mkd 。 

授权 文件 支持 包含 语句 ， 可 以 将 授权 文件 分 成 多 个 独立 的 单元 。 
执行 外 部 命令 ， 如 rsync 。 

Subversion 版 本 库 支 持 。 


如 果 在 同一 个 服务 器 上 以 svn+ssh 方 式 运行 Subversion 服 务 器 ， 可 
以 使 用 同一 套 公 铀 ， 同 时 为 用 户 提 供 Git 和 Subversion 服 务 。 


HTTP 口 令 文 件 维护 。 通 过 名 为 htpasswd 的 SSH 子 命令 实现 。 


第 31 章 ” Gitosis 服 务 架 设 


Gitosis 是 Gitolite 的 时 祖 ， 同 样 也 是 一 款 基于 SSH 公 钥 认 证 的 Git 服 
务 管理 工具 ， 但 是 功能 要 比 之 前 介绍 的 Gitolite 弱 一 些 。Gitosis 由 
Python 语言 开发 ， 对 于 偏爱 Python 不 喜欢 Per 的 开发 者 (我 就 是 其 中 之 
一 ) ， 可 以 对 Gitosis 加 以 关注 。 


Gitosis 的 出 现 远 早 于 Gitolite， 作 者 Tommi Virtanen 从 2007 年 5 月 就 
开始 了 Gitosis 的 开发 ， 最 后 一 次 提交 是 在 2009 年 9 月 ， 已 经 停止 更 新 
了 。 但 是 Gitosis 依 然 有 其 生命 力 。 


配置 滑 话 ， 可 以 直接 在 服务 器 端 编辑 ， 可 成 为 针对 某 些 服务 定制 
的 、 内 置 的 、 无 须 管理 的 Git 服 务 。 


Gitosis 的 配置 文件 非常 简单 ， 直 接 保 存 于 服务 安装 用 户 (如 git) 
的 主 目录 下 的 .gitosis.conf 文 件 中 ， 可 以 直接 在 服务 器 端 创建 和 编辑 。 
而 与 之 相 比 ，Gitolite 的 授权 文件 需要 复杂 的 编译 ， 一 般 需 要 管理 员 死 
隆 gitolite-admin 库 ， 远 程 编辑 并 推送 至 服务 器 。 若 要 用 Gitolite 实 现 一 
个 无 须 管 理 的 Git 服 务 ， 难 度 要 大 很 多 。 


文 持 版 本 库 重 定 癌 。 


版 本 库 重 定向 一 方面 在 版 本 库 路 径 变更 后 保持 旧 的 URL 仍 可 工 
作 ， 另 一 方面 用 在 客户 端 ， 以 简洁 的 地 址 屏蔽 服务 器 端 复杂 的 地 址 。 
例如 我 开发 的 一 款 备份 工具 (Gistore) ， 版 本 库 位 
于 /etc/gistore/tasks/system/repo.git 〈 符 号 链接 ) ， 客 户 端 使 用 System.git 
即 映射 到 复杂 的 服务 器 端 地 址 


注 : 我 在 定制 的 Gitolite， 这 个 功能 也 已 实现 。 


Python 语 言 开 发 ， 对 于 喜欢 Python 丰 喜欢 Perl 的 用 户 可 以 选择 


Gitosis ° 


在 Github 上 有 很 多 Gitosis 的 克隆， 我 对 Gitosis 的 改动 放 在 了 github 


上 : http://github.com/ossxp-com/gitosis ° 


因为 Gitosis 是 Gitolite 的 蜡 祖 ， 因 此 下 面 介绍 的 Gitosis 实 现 机 理会 
让 您 感到 似曾相识 : 


Gitosis 安 装 在 服务 器 (如 server) 的 某 个 账号 (如 git) 之 下 。 


un 


理 员 通过 git 命 令 检 出 名 为 gitosis-admin 的 版 本 库 。 
$git clone git@server:gitosis-admin.git 


理 员 将 git 用 户 的 公 钥 保存 在 gitosis-admin 库 的 keydir 目 孙 下 ， 并 
as 用 户 授 权 。 


当 管理 员 提 区 对 gitosis-admin 库 的 修改 并 推送 到 服务 右 之 后 ， 服 务 
郁 上 gitosis-admin 版 本 库 的 钩子 脚本 将 执行 相应 的 设置 工作 。 


O 痢 用 户 公 钥 目 动 退 加 到 服务 吉 端 安 闭 账 豆 用 户主 目 孙 中 
的 .ssh/authorized_keys 文 件 中 ， 并 设置 新 用 户 的 登录 shell 为 gitosis 的 一 
条 命令 gitosis-serve 。 
command="gitosis-serve 


Jiangxin",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty ssh-rsa< 公 和 钥 内 容 来 自 于 jiangxin.pub...> 


O 更 新 服务 器 端的 授权 文件 ~/.gitosis.conf 。 

用 户 可 以 用 Git 命 令 访问 授权 的 版 本 库 。 

当 管 理 员 授 权 后 ， 用 户 可 以 远程 在 服务 器 上 创建 新 版 本 库 。 

下 面 介绍 Gitosis 的 部 署 和 使 用 。 在 下 面 的 示例 中 约定 : 服务 器 的 
名 称 为 serverGitosis 的 安装 账号 为 git 。 


31.1 ”安装 Gitosis 


Gitosis 的 部 署 和 使 用 可 以 直接 参考 源 代码 中 的 README.rst。 可 以 
直接 访问 Github 上 我 的 Gitosis 克 隆 ， 因 为 Github 能 够 直接 将 rst 文 件 显示 


http://github.com/ossxp-com/gitosis/blob/master/README.rst 


31.1.1 ”Gitosis 的 安装 


Gitosis 的 官方 Git 库 位 于 git://eagain.net/gitosis.git。 我 在 Github 上 创 
建 了 一 个 克隆 趾 。Gitosis 的 安装 需要 在 服务 器 端 执 行 。 下 面 介 绍 直 接 
从 源 代码 进行 安装 ， 以 便 获 得 最 新 的 改进 。 


使 用 Git 下 载 Gitosis 的 源 代 码 。 
$git clone git://github.com/ossxp-com/gitosis.git 
进入 gitosis 目 录 ， 执 行 安装 。 


$cd gitosis 
$sudo python setup.py install 


可 执行 脚本 安装 在 /usr/local/bin 目 好 下 。 


$ls/usr/local/bin/gitosis-* 
/usr/local/bin/gitosis-init/usr/local/bin/gitosis-run-hook 
/usr/local/bin/gitosis-serve 


[1| http://github.com/ossxp-com/gitosis 


31.1.2 ”服务 器 端 创建 专用 账号 
安装 Gitosis， 还 需要 在 服务 器 端 创建 专用 账号 ， 所 有 用 户 都 通过 
此 账号 访问 Git 库 。 一 般 为 方便 易 记 ， 选 择 git 作 为 专用 账号 名 称 。 


$sudo adduser--system--shell/bin/bash--disabled-password--group 
git 


创建 用 户 git， 并 设置 用 户 的 shell 为 可 登录 的 shell， 如 /bin/bash， 同 
时 添加 同名 的 用 户 组 。 


有 的 系统 ， 只 允许 特定 用 户 组 (如 ssh 用 户 组 ) 的 用 户 才 可 以 通过 
SSH 协 议 登录 ， 这 就 需要 将 新 建 的 git 用 户 添加 到 ssh 用 户 组 中 。 


$sudo adduser git ssh 


31.1.3 ”Gitosis 服 务 初始 化 


Gitosis 服 务 初始 化 ， 束 是 初始 化 一 个 gitosis-admin 库 ， 并 为 管理 员 
分 配 权 限 ， 还 要 将 Gitosis 管 理 员 的 公 钥 添加 到 专用 账号 的 
一 /.ssh/authorized_keys 文 件 中 ， 具 体操 作 过 程 如 下 。 


(1) 如 果 管 理 员 在 客户 端 没 有 公 钥 ， 使 用 下 面 的 命令 创建 


$ssh-keygen 


(2) 管理 员 上 传 公 钥 到 服务 器 。 


$scp~/.ssh/id_rsa,pub server:/tmp 


(3) 服务 器 端 进行 Gitosis 服 务 初始 化 。 
以 git 用 户 身 份 执行 gitosis-init 命 令 ， 并 向 其 提供 管理 员 公 钥 。 


$sudo su-git 
$gitosis-init</tmp/id_rsa.pub 


(4) 确保 gitosis-admin 版 本 库 的 钩子 脚本 可 执行 。 


$sudo chmod a+x~git/repositories/gitosis-admin.git/hooks/post- 
update 


31.2 ”管理 Gitosis 
31.2.1 管理 员 克 隆 gitolit-admin 管 理 库 


当 Gitosis 安 闭 完 成 后 ， 在 服务 器 端 目 动 创建 了 一 个 用 于 Gitosis 目 
吴 管 理 的 Git 库 : gitosis-admin.git 。 


管理 员 在 客户 端 克 隆 gitosis-admin.git 库 ， 注 意 要 确保 认证 中 使 用 
的 是 正确 的 公 角 : 
$git clone git@server:gitosis-admin.git 
$cd gitosis-admin/ 
$1s-F 
gitosis.conf keydir/ 


$1s keydir/ 
jiangxin.pub 


可 以 看 出 gitosis-admin 目 录 下 有 一 个 配置 文件 和 一 个 目录 keydir。 
keydir/jiangxin.pub 文 件 


keydir 目 孙 下 初始 时 只 有 一 个 用 户 公 钥 ， 即 管理 员 的 公 铀 。 管 理 
员 的 用 户 名 来 目 公 钥 文件 末尾 的 用 户 和 名 。 


gitosis.conf 文 件 


人 


该 文件 为 授权 文件 。 初 始 内 容 为 : 


1 [gitosis] 
2 


3 [group gitosis-admin] 
4 writable=gitosis-admin 
5 members=jiangxin 


可 以 看 到 授权 文件 的 语法 完全 不 同 于 之 前 介绍 的 Gitolite 的 授权 文 
整个 授权 文件 以 用 户 组 为 核心 ， 而 非 版 本 库 为 核心 。 


OO 第 3 行 开 始 定义 了 一 个 用 户 组 gitosis-admin 。 
OO 第 5 行 设 定 了 该 用 户 组 包含 的 用 户 列表 。 


初始 时 只 有 一 个 用 户 ， 即 管理 员 公 钥 所 属 的 用 户 。 


O 第 4 行 设 定 了 该 用 户 组 对 哪些 版 本 库 具 有 写 操作 。 


在 这 里 ， 配 置 对 gitosis-admin 版 本 库 具 有 写 操 作 。 写 操作 目 动 包含 


了 读 操 作 。 


31.2.2 ”增加 新 用 户 


增加 新 用 户 ， 就 是 允许 新 用 户 能 够 通过 其 公 钥 访问 Git 服 务 。 只 
将 新 用 户 的 公 钥 添加 到 gitosis-admin 版 本 库 的 keydir 目 录 下 ， 即 完成 新 
用 户 的 添加 ， 有 具体 操作 过 程 如 下 。 


(1) 管理 员 从 用 户 获 取 公 铀 ， 并 将 公 钥 按照 username.pub 格 式 进 
行 重 命名 。 


用 户 可 以 通过 邮件 或 其 他 方式 将 公 钥 传递 给 管理 员 ， 切 记 不 要 将 
私 钥 误 传 给 管理 员 。 如 果 发 生 私 钥 泄 露 ， 马 上 重新 生成 新 的 公 钥 / 私 铀 
对 ， 并 将 新 的 公 钥 传递 给 管理 员 ， 并 申请 将 旧 的 公 钥 作废 。 


关于 公 角 名称， 我 引入 了 类 似 Gitolite 的 实现 : 


用 户 从 不 同 的 客户 端 主机 访问 有 着 不 同 的 公 铀 ， 如 果 硕 望 使 用 同 
一 个 用 户 名 进行 授权 ， 可 以 按照 uIsemame@host.pub 的 方式 命名 公 钥 文 
件 ， 和 名 为 username@pub 的 公 钥 指 辐 同一 个 用 户 username。 


也 文 持 邮 件 地 址 格式 的 公 铀 ， 即 形 如 username@gmailcom.pub 的 
公 钥 。Gitosis 能 够 很 智能 地 区 分 是 以 邮件 地 址 命名 的 公 钥 还 是 相同 用 
户 在 不 同 主机 上 的 公 铀 。 如 有 果 有 是 邮件 地 址 命名 的 公 钥 ， 将 以 整个 邮件 
地 址 作为 用 户 名 。 


(2) 管理 员 进 入 gitosis-admin 本 地 克隆 版 本 库 中 ， 复 制 新 用 户 公 
钥 到 keydir 目 录 。 


$cp/path/to/devi.pub keydir/ 
$cp/path/to/dev2.pub keydir/ 


(3) 执行 git add 命 令 ， 将 公 钥 添加 到 版 本 库 。 


$git add keydir 

$git status 

#0n branch master 

#Changes to be committed: 

#(USse "git reset HEAD<file>..."to unstage) 
# 

#new file:keydir/devi.pub 

#new file:keydir/dev2.pub 

# 


(4) 执行 git commit， 完 成 提交 。 


$git commit-m "add user:devi1,dev2" 
[master d7952a5l]add user:devi,dev2 
2 files changed,2 insertions(+),0 deletions(-) 
create mode 100644 keydir/devi.pub 
create mode 100644 keydir/dev2.pub 


(5) 执行 gt push， 同 步 到 服务 器 ， 才 真正 完成 新 用 户 的 添加 。 


$git push 

Counting objects:7,done. 

Delta compression using up to 2 threads. 
Compressing objects:100%(5/5),done. 
Writing objects:100%(5/5),1.03 KiB, done. 
Total 5(delta 0),reused 0O(delta 0) 

To git@server:gitosis-admin.git 


2482e1b. .d7952a5 master->master 


如 果 这 时 查看 服务 絮 端 ~git/.ssh/authorized_keys 文 件 ， 会 发 现 狐 
增 的 用 户 公 钥 也 附加 在 其 中 : 


###autogenerated by gitosis,DO NOT EDIT 
command="gitosis-serve 
Jiangxin",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty 
< 用 户 jiangxin 的 公 钥 .. .> 
command="gitosis-serve 
devi",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty ssh-rsa 
< 用 户 dev1 的 公 钥 .,. .> 
command="gitosis-serve 
dev2",no-port-forwarding,no-X11-forwarding,no-agent- 
forwarding,no-pty ssh-rsa 
< 用 户 dev1 的 公 钥 .. .> 


31.2.3 更改 授权 


新 用 户 添 加 完毕 后 ， 可 能 需要 重新 进行 授权 。 更 改 授权 的 方法 也 
非常 简单 ， 即 修改 gitosis.conf 配 置 文件 ， 提 交 并 推送 ， 有 具体 操作 过 程 
如 下 。 


(1) 首先 ， 管 理 员 进入 gitosis-admin 本 地 克隆 版 本 库 中 ， 编 辑 


gitosis.conf 。 


$vi gitosis.conf 


(2) 授权 指令 比较 复杂 ， 先 通过 建立 一 个 新 用 户 组 并 授权 新 版 本 
库 testing 壬 试 一 下 更 改 授权 文件 。 例 如 在 gitosis.conf 中 添加 如 下 的 授权 


内 容 : 


[group testing-admin] 
members=jiangxin@gitosis-admin 
admin=testing 


[group testing-devloper] 
members=dev1 dev2 
writable=testing 


ON=OORRODPc 


9 [group testing-reader] 
10 members=@all 
11 readonly=testing 


上 面 的 授权 文件 为 版 本 库 testing 赋 予 了 三 个 角色 。 分 别 是 
@testing-admin 用 户 组 、@testing-developer 用 户 组 和 @testing-reader 用 
户 组 。 


第 1 行 开始 的 testing-admin 小 节 ， 定 义 了 用 户 组 @testing-admin。 


第 2 行 设 定 该 用 户 组 包含 的 用 户 有 jiangxin， 以 及 前 面 定 义 的 
@gitosis-admin 用 户 组 用 户 。 
第 3 行 用 admin 指 令 ， 设 定 该 用 户 组 用 户 可 以 创建 版 本 库 testing 。 


admin 指 令 生 笔 考 狐 增 的 授权 指令 ， 请 确认 安装 的 Gitosis 包 侣 笔者 的 改 


进 。 


第 7 行 用 writable 授 权 指 令 ， 设 定 该 @testing-developer 用 户 组 用 户 
可 以 读 写 版 本 库 testing。 笔 者 改进 后 的 Gitosis 也 可 以 使 用 write 作 为 
writable 指 令 的 同义词 指令 。 


第 11 行 用 readonly 授 权 指 令 ， 设 定 该 @testing-reader 用 户 组 用 户 
(所 有 用 户 ) 可 以 只 读 访 问 版 本 库 testing。 笔 者 改进 后 的 Gitosis 也 可 以 
使 用 read 作 为 readonly 指 令 的 同义词 指令 。 


(3) 编辑 结束 ， 提 交 改 动 。 


$git add gitosis.conf 
$git commit-q-m "auth for repo testing." 


(4) 执行 git push， 同 步 到 服务 器 ， 才 真正 完成 授权 文件 的 编 


$git push 


31.3 ”Gitosis 授 权 详 解 


31.3 


1 
2 
3 
4 
5 
6 


日 
征 女 


.1 _  Gitosis 默 认 设 置 


在 [gitosis] 小 节 中 定义 Gitosis 的 默认 设置 如 下 : 


[gitosis] 

repositories=/gitroot 
#1l0oglevel=DEBUG 

gitweb=yes 

daemon=yes 
generate-files-in=/home/git/gitosis 


其 中 : 


第 2 行 ， 设 置 版 本 库 默 认 的 根 目录 是 /gitroot 目 录 。 否 则 默认 的 路 径 
闭 用 户主 目录 下 的 repositories 目 录 。 


第 3 行 ， 如 有 果 打 开 注 释 ， 则 版 本 库 操作 时 显示 Gitosis 的 调试 信息 。 


第 4 行 ， 启 用 Gitweb 的 整合 。 可 以 通过 [repo name] 小 和 为 版 本 库 设 


置 描述 字段 ， 将 会 显示 在 Gitweb 中 。 


第 5 行 ， 启 用 git-daemon 的 整合 。 即 在 新 创建 的 版 本 库 中 ， 创 建文 


件 git-daemon-export-ok 。 


第 6 行 ， 设 置 创 建 的 项 目 列表 文件 〈 供 Gitweb 使 用 ) 所 在 的 目录 。 
默认 为 安装 用 户主 目录 下 的 gitosis 目 录 。 


31.3.2 ”管理 版 本 库 gitosis-admin 


1 [group gitosis-admin] 
2 write=gitosis-admin 

3 members=jiangxin 

4 repositories=/home/git 


除了 第 4 行 ， 其 他 内 容 在 前 面 都 已 经 介绍 过 了 ， 是 Gitosis 目 身 管 理 
版 本 库 的 用 户 组 设置 。 

第 4 行 ， 重 狐 设置 了 版 本 库 的 默认 根 路 经 ， 有 履 善 默认 的 [gitosis] 小 
节 中 的 默认 根 路 径 。 实 际 的 gitosis-admin 和 版 本 库 的 路 径 


为 home/git/gitosis-admin.git 。 


31.3.3 ”定义 用 户 组 和 授权 


下 面 的 两 个 示例 小 节 定义 了 两 个 用 户 组 ， 并 且 用 到 了 路 径 变 换 的 


指令 。 


[group ossxp-admin] 
members=@gitosis-admin jiangxin 
admin=ossxp/** 


map admin redmine-*=ossxp/redmine/\1 


1 
2 
3 
4 read=gistore/* 
5 
6 


map admin ossxp/redmine-*=ossxp/(redmine-.*):ossxp/redmine/\1 
7 map admin ossxp/testlink- 
*=ossxp/(testlink-.*):ossxp/testlink/\1 
8 map admin ossxp/docbones*=ossxp/(docbones.*):ossxp/docutils/\1 


9 


10 [group alll] 
11 read=ossxp/** 


12 map 
13 map 
14 map 
15 map 
16 map 


read redmine-*=ossxp/redmine/\1 

read testlink-*=ossxp/testlink/\1 

read pysvnmanager-gitsvn=mirrors/pysvnmanager-gitsvn 
read ossxp/redmine-*=ossxp/(redmine-.*):ossxp/redmine/\1 
read ossxp/testlink- 


*~=ossxp/(testlink-.*):ossxp/testlink/\1 


17 map 


read ossxp/docbones*=ossxp/(docbones.*):ossxp/docutils/\1 


18 repositories=/gitroot 


在 上 面 的 示例 中 ， 演 示 了 授权 指令 及 Gitosis 特 色 的 map 指 令 。 


第 1 行 ， 定义 了 用 户 组 @ossxp-admin 。 


第 2 行 ， 设 定 该 用 户 组 包含 用 户 jiangxin 及 用 户 组 @gitosis-admin 的 


所 有 有 用户。 


第 3 行 ， 设 定 该 用 户 组 具有 创建 及 读 写 与 通配符 ossxp/** 匹 配 的 版 
本 库 的 权限 。 两 个 星 号 匹配 任意 字符 ， 包 括 路 径 分 隅 符 (/) 。 此 功能 
属于 笔者 扩展 的 功能 。 


第 4 行 ， 设 定 该 用 户 组 可 以 只 读 访 问 gistore/* 匹 配 的 版 本 库 。 一 个 
星 号 匹配 任意 字符 ， 路 径 分 陋 符 (/) 除外 。 此 功能 也 属于 笔者 扩展 的 


四 


[es 


过 


CC 


第 5 行 ， 是 Gitosis 特 有 的 版 本 库 名 称 重 定位 功能 。 


即 对 redmine-* 匹 配 的 版 本 库 ， 经 过 名 称 重 定位 ， 在 名 称 前 面 加 上 
ossxp/remdine。 其 中 \1 代 表 匹 配 的 整个 版 本 库 名 称 。 


用 户 组 @ossxp-admin 的 用 户 对 于 重 定位 后 的 版 本 库 具 有 admin ( 创 
建 和 读 写 ) 的 权限 。 


第 6 行 ， 是 我 扩展 的 版 本 库 名 称 重 定位 功能 ， 支 持 正则 表达 式 。 


等 号 左边 的 名 称 进行 通配符 匹配 ， 匹 配 后 ， 再 经 过 右 侧 的 一 对 正 
则 表达 式 进 行 转换 (冒号 前 的 用 于 匹配 ， 冒 号 后 的 用 于 替换 ) 。 


第 10 行 ， 使 用 了 内 置 的 @all 用 户 组 ， 因 此 不 需要 通过 members 设 
定 用 户 ， 因 为 所 有 用 户 均 属 于 该 用 户 组 。 


第 11 行 ， 设 定 所 有 用 户 均 可 以 只 读 访问 ossxp/#* 匹 配 的 版 本 库 。 


第 12~17 行 ， 对 特定 路 径 进行 映射 ， 并 分 配 只 读 权 限 。 


第 18 行 ， 设 置 版 本 库 的 根 路 径 为 /gitroot， 而 非 默认 的 版 本 库 根 路 


31.3.4 ”Gitweb 整 合 


Gitosis 和 Gitweb 的 整合 提供 了 两 个 方面 的 内 容 。 一 个 钙 可 以 设置 
版 本 库 的 描述 信息 ， 用 于 在 Gitweb 的 项 目 列表 页 面 中 显示 。 另 外 一 个 
是 自动 生成 项 目的 列表 文件 供 Gitweb 参 考 ， 避 免 Gitweb 使 用 低 效 率 的 
目 孙 递归 搜索 得 找 Git 版 本 库 列表 。 


例如 在 gitosis.conf 中 ， 下 面 的 配置 用 于 对 redmine-1.0.x 版 本 库 的 


Gitweb 整 合 进行 设置 。 


1 [repo ossxp/redmine/redmine-1.0.x] 

2 gitweb=yes 

3 owner=Jiang Xin 

4 description=Redmine 1.0.x 群 英 汇 定制 开发 


第 1 行 ，repo 小 节 设 定 版 本 库 的 路 径 。 


版 本 库 的 实际 路 径 是 用 版 本 库 默 认 的 根 〈 即 在 [gitosis] 小 节 中 定义 
的 或 默认 的 ) 加 上 此 小 节 中 的 版 本 库 路 径 组 合 而 成 的 。 


第 2 行 ， 局 用 Gitweb 整 合 。 如 果 省 略 ， 使 用 全 局 [gitosis] 小 下 中 
Gitweb 的 设置 。 


第 3 行 ， 用 于 设置 版 本 库 的 属 主 。 


第 4 行 ， 用 于 设置 版 本 库 的 摘 述 信息 ， 显 示 在 Gitweb 的 版 本 库 列 表 


每 一 个 repo 小 节 所 指向 的 版 本 库 ， 如 采 启 用 了 Gitweb 选 项 ， 则 版 
本 库 名 称 汇总 到 一 个 项 目 列表 文件 中 。 该 项 目 列表 文件 默认 保存 在 


~/gitosis/projects.list 中 。 


31.4 创建 新 版 本 库 


Gitosis 维 护 的 版 本 库 位 于 安 闭 用 户主 目录 下 的 repositories 目 录 中 ， 
即 如 果 安 装 用 户 为 git， 则 版 本 库 都 创建 在 home/git/repositories 目 录 之 
下 。 可 以 通过 配置 文件 gitosis.conf 修 改 默 认 的 版 本 库 的 根 路 径 。 


可 以 直接 在 服务 右 端 创建， 或 者 在 客户 剖 远 程 创建 版 本 库 。 


在 客户 端 远 程 创建 版 本 库 时 ，Gitosis 的 原始 实现 是 这 样 的 : 对 版 
本 库 具 有 writable ( 读 写 ) 权限 的 用 户 ， 当 对 一 个 不 存在 的 版 本 库 执 行 
克隆 操作 时 会 目 动 创建 版 本 库 ， 克 隆 即 创建 。 但 是 我 认为 这 不 是 一 个 
好 的 实践 ， 会 经 常 因 为 在 克隆 时 把 URL 写 错 ， 从 而 导致 在 服务 器 端 创 
建 垃圾 版 本 库 。 笔 者 改进 的 实现 如 下 : 


增加 了 名 为 admin (或 init) 的 授权 指令 ， 只 有 具有 此 授权 的 用 
户 ， 才 能 够 创建 版 本 库 。 


只 具有 writable (或 write) 权限 的 用 户 ， 不 能 在 服务 器 上 创建 版 本 


不 是 通过 克隆 创建 版 本 库 ， 而 十 在 对 版 本 库 进行 推送 的 时 候 创 
建 。 当 克隆 一 个 不 存在 的 版 本 库 时 会 报错 退出 。 


远程 在 服务 器 上 创建 版 本 库 的 方法 如 下 : 
(1) 首先 本 地 建 库 。 


$mkdir Somerepo 

$cd somerepo 

$git init 

$git commit--allow-empty 


(2) 使 用 git remote 指 令 添加 远程 版 本 库 。 


$git remote add origin git@server:ossxp/somerepo.git 


(3) 运行 git push 完 成 在 服务 器 端 版 本 库 的 创建 。 


$git push origin master 


31.5” 轻 量 级 管理 的 Git 服 务 


轻 量 级 管理 的 售 义 是 不 采用 默认 的 稍 嫌 复 杂 的 管理 模式 (远程 殉 
隆 gitosis-admin 库 ， 修 改 并 推送 的 管理 模式 ) ， 而 是 直接 在 服务 器 端 通 
过 预 完 定制 的 配置 文件 提供 Git 服 务 。 这 种 轻 量 级 管理 模式 ， 对 于 为 某 
些 应 用 建立 快速 的 Git 库 服务 提供 了 便利 。 


例如 在 使 用 备份 工具 Gistore 进 行文 件 备份 时 ， 可 以 用 Gitosis 架 设 
轻 量 级 的 Git 服 务 ， 可 以 在 远程 使 用 Git 命 令 进行 双 机 甚至 是 异地 备 


一 
Pe 
> 


目 先 创建 一 个 专用 账号 ， 并 设置 该 用 户 只 能 执行 gitosis-serve 命 
令 。 例 如 创建 账号 gistore， 通 过 修改 /etc/ssh/sshd_config 配 置 文件 ， 实 
现 限制 该 账号 登录 的 可 执行 命令 。 


Match user gistore 

ForceCommand gitosis-serve gistore 
X11iForwarding no 
AllowTcpForwarding no 
AllowAgentForwarding no 
PubkeyAuthentication yes 
#PasswordAuthentication no 


上 述 配 置信 息 告 诉 SSH 服 务 器 ， 几 十 以 gistore 用 户 登 录 的 账号 ， 


都 将 强制 执行 Gitosis 的 命令 : gitosis-serve gistore 。 


然后 ， 在 该 用 户 的 主 目录 下 创建 一 个 配置 文件 .gitosis.conf (注意 
文件 名 前 面 的 点 号 ) ， 如 下 : 


[gitosis] 
repositories=/etc/gistore/tasks 
gitweb=yes 

daemon=no 

[group gistore] 

members=gistore 

map readonly*=(.*):\1i/repo 


上 上述 配置 的 含义 古 : 


只 有 用 户 gistore 才 能 够 访问 /etc/gistore/tasks 下 的 Git 库 。 


版 本 库 的 名 称 需 要 变换 ， 例 如 system 库 会 变换 为 实际 路 


径 /etc/gistore/tasks/system/repo.git 。 


第 32 章 ”Gerrit 代 人 码 审核 服务 需 


谷歌 Android 开 源 项 目 在 Git 的 使 用 上 有 两 个 重要 的 创新 ， 一 个 是 
为 多 版 本 库 协 同 而 引入 的 repo， 这 在 前 面 第 25 划 已 经 详细 讨论 过 。 男 
外 一 个 重要 的 创新 束 是 Gerrit 一 一 代码 审核 服务 器 。Gerrit 为 Git 引 入 的 
代码 审核 是 强制 性 的 ， 也 区 ® 是 说 除非 特别 的 授权 设置 ， 同 Git 版 本 库 的 
推送 必须 要 经 过 Gerrit 服 务 器 ， 修 订 必 须 经 过 代码 审核 的 一 套 工作 流 之 
后 ， 才 可 能 经 批准 并 纳入 正式 代码 库 中 。 


首先 贡献 者 的 代码 通过 git 命 令 〈 或 repo 封 装 ) 推送 到 Gerrit 管 理 下 

的 Git 版 本 库 ， 推 送 的 提交 转化 为 一 个 一 个 的 代码 审核 任务 ， 审 核 任务 
可 以 通过 refs/changes/ 下 的 引用 访问 到 。 代 码 审 核 者 可 以 通过 Web 界 面 
查看 审核 任务 、 代 码 变 更 ， 通 过 Web 界 面 做 出 通过 代码 审核 或 打 回 等 
决定 。 测 试 者 也 可 以 通过 refs/changes/ 之 下 的 引用 获取 修订 然后 对 其 进 
行 测试 ， 如 果 测 试 通过 束 可 以 将 该 评审 任务 设置 为 校 蛤 通过 

(verified) 。 最 后 经 过 了 审核 和 校 验 的 修订 可 以 通过 Gerrit 界 面 中 的 提 
区 动作 合并 到 版 本 库 对 应 的 分 文中 。 


Android 项 目 网 站 上 有 一 个 代码 贡献 流程 图 趾 ， 详 细 地 介绍 了 
Gerrit 代 码 审 核 服 务 絮 的 工作 流程 。 翻 译 后 的 工作 流程 图 如 图 32-1。 


@ wz 
图 作者 本 培 
DO as 
全 wn 
| #4 
全 erit pata 


打 自 ;http-j/source angroid corm/sourcefife-of.3.pch html 


32-1 ”Gerrit 代码 审 核 工作 流 


32.1 ”Gerrit 的 实现 原理 


Gerrit 更 准确 地 说 应 该 称 为 Gerrit2。 因 为 Android 项 目 最 早 使 用 的 
评审 服务 器 Gerrit 不 是 今天 这 个 样子 的 。 最 早 版 本 的 Gerrit 是 用 Python 
开发 运行 于 Google App Engine 上 的 ， 从 Python 之 父 Guido van Rossum 开 
发 的 Rietveld 分 文 而 来 。 在 这 里 要 讨论 的 Gerrit 实 为 Gerrit2， 是 用 Java 语 
言 实现 的 名 。 


1.SSH 协 议 的 Git 服 务 器 


Gerrit 本 身 基于 SSH 协 议 实 现 了 一 套 Git 服 务 器 ， 这 样 束 可 以 对 Git 
数据 推送 进行 更 为 精确 的 控制 ， 为 强制 审核 的 实现 建立 了 基础 。 


Gerrit 扣 供 的 Git 服 务 的 问 口 并 非 标 准 的 22 端 口 ， 默 认 是 29418 站 
口 。 这 个 端口 是 可 以 被 发 现 的 ， 当 访问 Gerrit 的 Web 界 面 时 可 以 得 到 这 
个 端口 。 对 Android 项 目的 代码 审核 服务 大 ， 访 问 
https://review.source.android.com/ssh_info 束 可 以 查看 到 Git 服 务 的 服务 虱 
域名 和 开放 的 端口 。 下 面 用 curl 命 令 查 看 网 页 的 输出 。 


$curl-L-k http://review.source.android.com/ssh_info 
review.source.android.com 29418 


2. 特 殊 引 用 refs/for 和 refs/changes 


Gerrit 的 Git 服 务 器 ， 禁 止 用 户 问 refs/heads 命 名 空间 下 的 引用 执行 
推送 (除非 特别 的 授权 ) ， 即 不 允许 用 户 直 接 向 分 支 进行 提交 。 为 了 
让 开发 者 能 够 癌 Git 服 务 器 提交 修订 ，Gerrit 的 Git 服 务 器 只 人 允许 用 户 疝 


特殊 的 引用 refs/fov<branch-name> 下 执行 推送 ， 其 中 <branch-name 
> 即 为 开发 者 的 工作 分 支 。 向 refs/fov<branch-name> 命名 空间 下 推送 
并 不 会 在 其 中 创建 引用 ， 而 是 为 新 的 提交 分 配 一 个 ID ， 称 为 review- 
id， 并 为 该 review-id 的 访问 建立 如 下 格式 的 引用 refs/changes/nn/< 


review-id>/m， 其 中 : 


review-id 是 Gerrit 为 评审 任务 顺序 而 分 配 的 全 局 唯一 的 号 码 。 


nn 为 review-id 的 后 两 位 数 ， 位 数 不 足 用 零 补 齐 。 即 nn 为 review-id 
除 以 100 的 余数 。 


mm 为 修订 号 ， 该 review-id 的 首次 提交 修订 号 为 1， 如 果 该 修订 被 打 


回 ， 重 新 提交 修订 号 会 自 增 。 


3.Git 库 的 钩子 脚本 hooks/commit-msg 


为 了 保证 已 经 提交 审核 的 修订 通过 审核 入 库 后 ， 如 果 被 别 的 分 文 
拣选 (cherry-pick) 后 再 推送 至 服务 器 时 不 会 产生 新 的 重复 的 评审 任 
务 ，Gerrit 设 计 了 一 套 特 殊 的 方法 ， 即 要 求 每 个 提交 在 提交 说 明 中 包含 
Change-Id 键 值 对 作为 标签 ， 该 标签 在 首次 生成 时 使 用 特殊 的 哈 希 算法 
以 保障 其 唯一 性 。 执 行 拣选 操作 时 ， 提 交 说 明 会 被 保持 ， 即 来 目 原 始 
提交 说 明 中 的 Change-Id 键 值 对 也 会 保持 不 变 ， 这 样 当 新 提交 推送 到 
Gerrit 服 务 器 时 ，Gerrit 会 发 现 新 的 提交 包含 了 已 经 处 理 过 的 Change- 


Id， 就 不 再 为 该 修订 创建 新 的 评审 任务 和 review-id， 而 直接 将 提交 入 
库 o 


为 了 使 得 Git 提 交 中 包含 唯一 的 Change-Id,Gerrit 提 供 了 一 个 钩子 脚 
本 ， 将 该 脚本 拷贝 到 开发 者 的 本 地 Git 库 的 钧 子 脚 本 目录 中 ， 即 脚本 文 
件 .giyhooks/commitrmsg。 这 个 钩子 脚本 在 用 户 提交 时 ， 自 动 在 提交 说 
明 中 创建 Change-Id 键 值 对 。 至 于 如 何 实现 Change-Id 值 的 唯一 性 ， 可 以 
参考 该 脚本 。 


当 Gerrit 获 取 到 用 户 向 refs/fov<branch-name> 推送 的 提交 中 包 
舍 "Change-Id:I..…………" 的 格式 时 ， 如 采 该 Change-Id 之 前 没有 见 过 ， 会 创 
建 一 个 新 的 评审 任务 并 分 配 新 的 review-id， 并 在 Gerrit 的 数据 库 中 保存 
Change-Id 和 review-id 的 关联 。 


如 果 用 户 的 提交 因为 某 种 原因 被 打 回 重 做 ， 开 发 者 修改 之 后 重新 
推送 到 Gerrit 时 就 要 注意 在 提交 说 明 中 使 用 相同 的 Change-Id (使 用 -- 
amend 提 交 即 可 保持 提交 说 明 ) ， 以 免 创 建新 的 评审 任务 。 还 要 在 推 
送 时 将 当前 分 支 推 送 到 refs/changes/<nn>/<review-id>/<m> 中 ,是 
为 该 评审 任务 的 一 个 新 的 修订 ， 其 中 <nn> 和 <review-id> 和 之 前 提 
交 的 评审 任务 的 修订 号 相同 ，<m> 则 要 人 工 选 择 一 个 新 的 修订 号 。 


以 上 说 起 来 很 复 洒 ， 但 是 在 实际 操作 中 只 要 使 用 repo 这 一 工具 ， 
忠 相 对 容易 多 了 。 


4. 其 余 一 切 交 给 Web 


Gerrit 男 外 一 个 重要 的 组 件 就 是 Web 服 务 器 ， 通 过 Web 服 务 器 实现 
对 整个 评审 工作 流 的 控制 。 关 于 Gerrit 工 作 流 ， 请 参见 本 章 开头 出 现 的 
Gerrit 工 作 流 程 图 。 


想 要 感受 一 下 Gerrit 的 魅力 ? 请 直接 访问 Android 项 目的 Gerrit 网 站 ;hwpsWreview, 
souree-anmdroid.coom/， 您 会 看 到 如 图 32-2 的 界面 。 
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图 32-2 Android 项 目 代码 审核 网 站 


点 击 菜单 中 的 “ 


“Merged” 即 可 显示 已 经 通过 评审 且 合并 到 代码 库 中 的 审核 任务 。 图 32-3 
中 显示 的 就 是 Andorid 一 个 已 经 合并 到 代码 库 
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图 32-3 Android 项 目的 16993 


从 图 32-3 中 可 以 看 出 : 


号 评审 


URL 中 显示 的 评审 任务 编号 为 16993。 
该 评审 任务 的 Change-Id 以 字母 开头， 包含 了 一 个 唯一 的 40 位 
SHA1 哈 希 值 。 


整个 评审 任务 有 三 个 人 参与 ， 一 个 人 进行 了 检查 
人 进行 了 代码 审核 。 


二 三 | 


查 (verify) ， 两 个 


该 评审 任务 的 状态 为 已 合并 : "merged"。 


该 评审 任务 总 共 包 含 两 个 补丁 集 : Patch set 1 和 Patch set 2。 
补丁 集 的 下 载 方法 是 : repo download platformy/sdk 16993/2。 


如 有 果 使 用 repo 命 令 获 取 促 丁 集 是 非常 方便 的 ， 因 为 封 洲 后 的 repo 
屏蔽 抒 了 Gerrit 的 一 些 实现 细节 ， 例 如 补丁 集 在 Git 库 中 的 存在 位 置 。 
如 前 所 述 ， 补 丁 集 实际 保存 在 refs/changes 命 名 空间 下 。 使 用 git 1s- 
remote 命 令 ， 从 Gerrit 维 护 的 代码 库 中 可 以 看 到 补丁 集 对 应 的 引用 名 


称 。 


$git ls-remote\ 
ssh://review.source.android.com:29418/platform/sdk\ 
refs/changes/93/16993* 

5fb1e79b01166f5192f11c5f509cf51f06ab023d refs/changes/93/16993/1 
d342ef5b41f07c0202bc26e2bfff745b7c86d5a7 refs/changes/93/16993/2 


接 下 来 瓯 来 介绍 一 下 Gerrit 服 务 器 的 部 效 和 使 用 方法 。 


[1| http://source.android.com/source/life-of-a-patch.html 


[2] http://code.google.com/p/gerrit/wiki/Background 


32.2 ”架设 Gerrit 上 服务 器 


1. 下 载 war 包 


Gerrit 是 由 Java 开 发 的 ， 被 封装 为 一 个 war 包 : gerrit,war， 安 逆 非 
常人 简洁 。 如 果 需 要 从 源码 编译 出 war 包 ， 可 以 参照 相关 文档 叫 。 不 过 
最 简单 的 就 是 从 Google Code 上 直接 下 载 编译 好 的 war 包 。 


从 下 面 的 地 址 下 载 Gerrit 的 war 包 : 
http://code.google.com/p/gerrit/downloads/list。 在 下 载 页 面 会 有 一 个 文 
件 名 类 似 Gerrit-x.x.x.war 的 war 包 ， 这 个 文件 丈 是 Gerrit 的 全 部 。 示 例 中 
使 用 的 是 2.1.5.1 版 本 ， 把 下 载 的 Gerrit-2.1.5.1.war 包 重 命名 为 
Gerrit.war。 下面 的 介绍 就 是 基于 这 个 版 本 。 


2. 数 据 库 选 择 


Gerrit 需 要 数据 库 来 维护 账户 信息 和 跟踪 评审 任务 等 。 目 前 支持 的 
数据 库 类 型 有 PostgreSQL、MySQL 及 峙 入 式 的 H2 数 据 库 。 


选择 使 用 默认 的 H2 内 置 数据 库 是 最 简单 的 ， 因 为 这 样 无 须 任 何 设 
置 。 如 果 想 使 用 更 为 熟悉 的 PostgreSQL 或 MySQL， 则 需要 预先 建立 数 
据 库 。 


对 于 PostgreSQL ， 在 数据 库 中 创建 一 个 用 户 gerrit， 并 创建 一 个 数 
据 库 reviewdb。 


createuser-A-D-P-E gerrit 
createdb-E UTF-8-0 gerrit reviewdb 


对 于 MySQL， 在 数据 库 中 创建 一 个 用 户 gerrit 并 为 其 设置 口令 (不 
要 真如 下 面 那 样 将 口令 设置 为 "secret") ， 并 创建 一 个 数据 库 


reviewdb ° 


$mysql-u root-p 

mysql>CREATE USER 'gerrit' @ 'localhost' IDENTIFIED BY 
'secret'; 

mysql> CREATE DATABASE reviewdb; 

mysql>ALTER DATABASE reviewdb charset=latini; 

mysql>GRANT ALL ON reviewdb.*TO 'gerrit '@ 'localhost'; 

mysql>FLUSH PRIVILEGES; 


3; 以 一 个 专用 用 户 账 号 雪 行 安装 


在 系统 中 创建 一 个 专用 的 用 户 账号 如 : gerrit。 以 该 用 户 吴 份 执行 
安装 ， 将 Gerrit 的 配置 文件 、 内 置 数据 库 、war 包 等 都 目 动 安 装 在 该 用 
户主 目录 下 的 特定 目录 中 。 

$sudo adduser gerrit 
$sudo su gerrit 


$cd~gerrit 
$java-jar gerrit.war init-d review site 


在 安装 过 程 中 会 提出 一 系列 问题 。 


(1) 创建 相关 目录 。 


默认 Grerit 在 安装 用 户主 目录 下 创建 review_site， 并 把 相关 文件 安 
在 这 个 日 录 之 下 。Git 版 本 库 的 根 路 径 默 认 位 于 此 目录 之 下 的 git 目 录 


车 


漆 


二 


***Gerrit Code Review 2.1.5.1 
类 类 


Create '/home/gerrit/review site' [Y/n]? 
***Git Repositories 
类 大 类 


Location of Git repositories[git]: 


(2) 选择 数据 库 类 型 。 
选择 H2 数 据 库 是 简单 的 选择 ， 无 须 额外 的 配置 。 


***SQL Database 
类 大 类 


Database server type[H2/?]: 


(3) 设置 Gerrit Web 界 面 认 证 的 类 型 。 


默认 为 openid， 即 使 用 任何 支持 OpenID 的 认证 源 (如 Google、 
Yahoo! ) 进行 身份 认证 。 此 模式 支持 用 户 自 建 账号 ， 用 户 通过 
OpenID 认 证 源 的 认证 后 ，Gerrit 会 自动 从 认证 源 获 取 相 关 属 性 如 用 户 
全 名 和 邮件 地 址 等 信息 创建 账号 。 Android 项 目的 Gerrit 服 务 器 即 采 用 
此 认证 模式 。 


如 果 有 可 用 的 LDAP 服 务 器 ， 那 么 ldap 或 1dap_bind 也 是 非常 好 的 认 
证 方式 ， 可 以 直接 使 用 LDAP 中 的 已 有 账号 进行 认证 ， 不 过 此 认证 方 
式 下 Gerrit 的 自 建 账号 功能 是 关闭 的 。 此 安装 示例 选择 的 就 是 LDAP 认 
证 方式 。 


HTTP 认 证 也 是 可 选 的 认证 方式 ， ee 
反 回 代理 ， 并 在 Apache 中 配置 Web 站 点 的 口令 认证 ， 通 过 口令 认证 后 
Gerrit 在 创建 账号 的 过 程 中 会 询问 用 户 的 邮件 地 址 并 发 送 确认 邮件 。 


***User Authentication 

。 

Authentication method[OPENID/?]:? 
Supported options are: 

openid 

http 

http_ldap 

ldap 

ldap_bind 
development_become_any_account 
Authentication method[OPENID/?]:1ldap 
LDAP server[ldap://localhost]: 
LDAP username: 

Account BaseDN:dc=foo,dc=bar 
Group BaseDN[dc=foo,dc=bar]: 


(4) 发 送 邮件 设置 。 


默认 使 用 本 机 的 SMTP 发 送 邮 件 。 


***Email Delivery 

党 滨 洋 

SMTP server hostname[localhost]: 
SMTP server port[(default)]: 
SMTP encryption[NONE/?]: 


SMTP USername : 


(5) Java 相关 设置 。 


使 用 OpenJava 和 Sun Java 均 可 。Gerrit 的 war 包 要 复制 到 
review_site/bin 目 好 中 。 


***Container Process 

类 大 类 

Run as[gerrit]: 

Java runtime[/usr/lib/jvm/java-6-sun-1.6.0.21/jrel]: 

Copy gerrit.war to/home/gerrit/review site/bin/gerrit.war[Y/n]? 
Copying gerrit.war to/home/gerrit/review_ site/bin/gerrit.war 


(6) SSH 服 务 相 关 设置 。 


Gerrit 的 基于 SSH 协 议 的 Git 服 务 非常 重要 ， 默 认 的 端口 为 29418。 
换 成 其 他 端口 也 无 妨 ， 因 为 repo 可 以 自动 探测 到 该 端口 。 


***SSH Daemon 

党 尖 滨 

Listen on address[*]: 

Listen on port[29418]: 

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144 

If available,Gerrit can take advantage of features 

in the library,but will1 also function without it. 

Download and install it now[Y/n]? 

Downloading http://www.bouncycastle.org/download/bcprov-jdk16- 
144.jar.. .OK 

Checksum bcprov-jdk16-144.jar OK 

Generating SSH host key...rsa...dsa...done 


(7) HTTP 服务 相关 设置 。 


默认 局 用 内 置 的 HTTP 服 务 器 ， 端 口 为 8080， 如 末 该 端口 被 占用 
(如 Tomcat) ， 则 需要 更 换 为 其 他 端口 ， 否 则 服务 局 动 失 败 。 如 下 例 
就 换 成 了 8081 端 口 。 


***HTTP Daemon 

Behind reverse proxy[y/N]?y 

Proxy uses SSL(https://)[y/N]?y 
Subdirectory on proxy server[/]:/gerrit 
Listen on address[*]: 

Listen on port[8081]: 

Canonical URL[https://localhost/gerrit]: 
Initialized/home/gerrit/review site 


4. 启 动 Gerrit 服 务 
Gerrit 服 务 正确 安装 后 ， 运 行 Gerrit 启 动 脚本 来 启动 Gerrit 服 务 。 


$/home/gerrit/review site/bin/gerrit.sh start 
Starting Gerrit Code Review:OK 


服务 正确 局 动 之 后 ， 会 看 到 Gerrit 服 务 打开 两 个 端口 ， 这 两 个 端口 
征 在 Gerrit 安 装 时 指定 的 。 您 的 输出 和 下 面 的 示例 可 能 略 有 不 同 。 


$sudo netstat-ltnplgrep-i gerrit 

tcp 0 0 0.0.0.0:8081 0.0.0.0:*LISTEN 
26383/GerritCodeRev 

tcp 0 0 0.0.0.0:29418 0.0.0.0:*LISTEN 
26383/GerritCodeRev 


5. 设 置 Gerrit 服 务 开 机 上 自动 启动 


Gerrit 服 务 的 启动 脚本 支持 start、stop、restart 参 数 ， 可 以 作为 init 
脚本 开机 目 动 执行 。 


$sudo ln-snf\ 
/home/gerrit/review site/bin/gerrit.sh\ 


/etc/init.d/gerrit. sh 
$sudo ln-snf.,./init.d/gerrit.sh/etc/rc2.d/S90gerrit 
$sudo ln-snf.,./init.d/gerrit.sh/etc/rc3.d/S90gerrit 


服务 目 动 局 动 脚本 /etc/init.d/gerrit.sh 和 需要 通 
过 /etc/default/gerritcodereview 提 供 一 些 默 认 的 配置 。 以 下 面 的 内 容 来 


创建 该 文件 。 


GERRIT_SITE=/home/gerrit/review site 
NO_START=0 


6.Gerrit 认 证 方式 的 选择 


如 果 是 开放 的 Gerrit 服 务 ， 使 用 OpenId 认 证 是 最 好 的 方法 ， 就 像 谷 
歌 Android 项 目的 代码 审核 服务 器 配置 的 那样 。 任 何人 只 要 在 可 以 作为 
OpenId 提 供 者 的 网 站 上 (如 Google、Yahoo! 等 ) 拥有 账号 ， 就 可 以 直 
接 通 过 OpenId 注 册 ，Gerrit 会 在 用 户 登 录 OpenId 提 供 者 网 站 成 功 后 ， 自 
动 获取 (经 过 用 户 的 确认 ) 用 户 在 OpenId 提 供 者 站 点 上 的 部 分 注册 信 
息 (如 用 户 全 名 或 邮件 地 址 ) 在 Gerrit 上 自动 为 用 户 创建 账号 。 


如 果 架 设 有 LDAP 服 务 器 ， 并 且 用 户 账号 都 在 LDAP 中 进行 管理 ， 
那么 采用 LDAP 认 证 也 是 非常 好 的 方法 。 登 录 时 提供 的 用 户 名 和 口令 


通过 LDAP 服 务 器 验证 之 后 ，Gerrit 会 自动 从 LDAP 服 务 器 中 获取 相应 
的 字段 属性 为 用 户 创 建 账号 。 因 为 创建 账号 的 用 户 全 名 和 邮件 地 址 来 
自 于 LDAP， 因 此 不 能 在 Gerrit 中 更 改 ， 但 是 用 户 可 以 注册 新 的 邮件 地 
址 。 我 在 配置 LDAP 认 证 时 遇 到 了 一 个 问题 就 是 创建 账号 的 用 户 全 名 
是 空白 的 ， 这 是 因为 没有 正确 设置 LDAP 的 相关 字段 。 如 果 LDAP 服 务 
器 使 用 的 是 OpenLDAPGerrit 会 从 displayName 字 段 获取 用 户 全 名 ， 如 
果 使 用 Active Directory 则 用 givenName 和 sn 字段 的 值 拼 接 形 成 用 户 全 
名 o 


Gerrit 还 支持 使 用 HTTP 认 证 ， 这 种 认证 方式 需要 架设 Apache 有 反问 
代理 ， 在 Apache 中 配置 HTTP 认 证 。 用 户 若 要 访问 Gerrit 网 站 ， 首 先 需 
要 通过 Apache 配 置 的 HTTP Basic Auth 认 证 ， 当 Gerrit 发 现 用 户 已 经 登 
录 后 ， 会 要 求 用 户 确认 邮件 地 址 。 当 用 户 确 认 邮 件 地 址 后 ， 再 填写 其 
他 必须 的 字段 完成 账号 注册 。HTTP 认 证 方式 的 缺点 除了 在 口令 文件 管 
理 上 需要 管理 员 手 工 维护 比较 麻烦 之 外 ， 还 有 一 个 缺点 就 是 用 户 一 旦 
登录 成 功 后 ， 想 退 出 登录 或 更 换 其 他 用 户 账号 登录 会 变 得 非常 麻 颅 ， 
除非 关闭 浏览 右 。 关 于 用 户 切换 有 一 个 小 窍门 : 例如 Gerrit 登 录 URL 为 
https://server/gerrit/login/， 则 用 浏览 器 访问 
https://nobody:wrongpass@server/gerrit/login/， 即 用 错误 的 用 户 名 和 口 
令 履 兰 掉 浏览 促 缓 存 的 认证 用 户 名 和 口令 ， 这 样 就 可 以 重 狐 认 证 了 。 


在 后 面 的 Gerrit 演 示 和 介绍 中 ， 为 了 设置 账号 的 方便 ， 使 用 了 
HTTP 认 证 ， 因 此 下 面 再 介绍 一 下 HTTP 认 证 的 配置 方法 。 


7. 配 置 Apache 代 理 访问 Gerrit 


默认 Gerrit 的 Web 服 务 端口 为 8080 或 8081， 通 过 Apache 的 反 向 代理 
就 可 以 使 用 标准 的 80 (HTTP) 或 443 (HTTPS) 来 访问 Gerrit 的 Web 界 
面 O 


ProxyRequests Off 

ProxyVia Off 

ProxyPreserveHost On 

<Proxy*> 

Order deny,allow 

Allow from all 

</Proxy> 
ProxyPass/gerrit/http://127.0.0.1:8081/gerrit/ 


如 果 要 配置 Gerrit 的 HTTP 认 证 ， 则 还 需要 在 上 面 的 配置 中 插入 
HTTP Basic Auth 认 证 的 设置 。 


<Location/gerrit/login/> 

AuthType Basic 

AuthName "Gerrit Code Review" 

Require valid-user 

AuthUserFile/home/gerrit/review site/etc/gerrit.passwd 
</Location> 


在 上 面 的 配置 中 ， 指 定 了 口令 文件 的 位 
置 : /home/gerrit/review_site/etc/gerrit.passwd。 可 以 用 htpasswd 命 令 维 


扩 该 口令 文件 。 


$touch/home/gerrit/review site/etc/gerrit.passwd 
$htpasswd-m/home/gerrit/review site/etc/gerrit.passwd jiangxin 
New password: 

Re-type new password: 

Adding password for user jiangxin 


至 此 为 止 ，Gerrit 服 务 安装 完成 。 在 正式 使 用 Gerrit 之 前 ， 先 来 研 
究 一 下 Gerrit 的 配置 文件 ， 以 免 安 装 过 程 中 遗漏 或 因 错误 的 设置 而 影响 
使 用 。 


[1| http://gerrit.googlecode.com/svn/documentation/2.1.5/dev-readme.html 


32.3 ”Gerrit 的 配置 文件 


Gerrit 的 配置 文件 保存 在 部 署 目 录 下 的 etc/gerrit.conf 文 件 中 。 如 果 
对 安装 时 的 配置 不 满意 ， 可 以 手工 修改 配置 文件 ， 重 启 Gerrit 服 务 即 
可 。 


全 部 采用 默认 配置 时 的 配置 文件 : 


[gerrit] 

basePath=git 
canonicalwWebUrl=http://localhost:8080/ 
[database] 

type=H2 

database=db/ReviewDB 

[auth] 

type=OPENID 

[sendemail] 

smtpServer=localhost 

[container] 

user=gerrit 
jJavaHome=/usr/1ib/jvm/java-6-openjdk/jre 


[sshd] 
listenAddress=*:29418 
[httpd] 
listenUrl=http://*:8080/ 
[cache] 


directory=cache 


如 果 采 用 LDAP 认 证 ， 下 面 的 配置 文件 片断 配置 了 一 个 支持 匿名 
绑 定 的 LDAP 服 务 器 配置 。 


[auth] 
type=LDAP 


[ldap] 
server=ldap://localhost 


accountBase=dc=foo, dc=bar 
groupBase=dc=foo, dc=bar 


如 条 采用 MySQL 而 非 玖 认 的 H2 数 据 库 ， 下 面 的 配置 文件 显示 了 相 
拓 了 大 直 


[database] 
type=MYSQL 
hostname=localhost 
database=reviewdb 
username=gerrit 


LDAP 绑 定 或 与 数据 库 连 接 的 用 户口 令 保存 在 etc/secure.config 文 件 
中 o 


[database] 
password=secret 


下 面 的 配置 将 Web 服 务 架 设 在 Apache 反 癌 代 理 的 后 面 。 


[httpd] 
listenUrl=proxy-https://*:8081/gerrit 


32.4 ”Gerrit 的 数据 库 访 问 


之 所 以 要 对 数据 库 访问 多 说 几 句 ， 是 因为 在 Web 界 面 往 往 无 法 配 
置 对 Gerrit 的 一 些 设置 ， 需 要 直接 修改 数据 库 ， 而 大 部 分 用 户 在 安装 
Gerrit 时 都 会 选用 内 置 的 H2 数 据 库 ， 可 能 大 部 分 用 户 并 不 了 解 如 何 操 
作 H2 数 据 库 。 


实际 上 无 论 选 择 何 种 数据 库 ，Gerrit 都 提供 了 两 种 数据 库 操 作 的 命 
令 行 接口 。 第 一 种 方法 是 在 服务 絮 端 调用 gerrit.war 包 中 的 命令 入 口 ， 
另外 一 种 方法 是 远程 SSH 调 用 接口 。 

对 于 第 一 种 方法 ， 需 要 在 服务 器 端 执行 ， 而 且 如 果 使 用 的 是 H2 内 


置 数据 库 还 需要 先 将 Gerrit 服 务 停 止 。 先 以 安装 用 户 的 喘 份 进入 Gerrit 
部 署 目 录 下 ， 再 执行 命令 调用 gerrit.war 包 ， 如 下 : 


$java-jar bin/gerrit.war gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134(2010-04-23)) 

Type '\h' for help.Type '\r' to clear the buffer. 
gerrit> 


当 出 现 "gerrit> "提示 符 时 ， 就 可 以 输入 SQL 语 句 操 作 数 据 库 了 。 


第 一 种 方式 需要 登录 到 服务 右上， 而 且 操 作 H2 数 据 库 时 还 要 预先 
停止 服务 ， 显 然 很 不 方便 。 但 是 这 种 方法 也 有 存在 的 必要 ， 就 古 不 需 


要 认证 ， 尤 其 是 在 管理 员 账 号 尚未 建立 之 前 吏 可 以 得 看 和 更 改 数据 
库 。 


当 在 Gerrit 上 注册 了 第 一 个 账号 时 ， 即 拥有 了 管理 员 账 号 ， 正 确 为 
该 账号 配置 公 钥 之 后 ， 就 可 以 访问 Gerrit 提 供 的 SSH 登 录 服 务 。Gerrit 
的 SSH 协 议 提 供 访问 数据 库 的 第 二 种 方法 。 下 面 的 命令 就 是 用 管理 员 
公 钥 登录 Gerrit 的 SSH 服 务 器 ， 操 作 数 据 库 。 虽 然 演 示 用 的 是 本 机 地 址 
(localhost) ， 但 是 操作 远程 服务 器 也 是 可 以 的 ， 只 要 拥有 管理 员 权 
限 。 


$ssh-p 29418 localhost gerrit gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134(2010-04-23)) 

Type '\h' for help.Type '\r' to clear the buffer. 
gerrit> 


运行 命令 gerrit gsql 连 接 Gerrit 的 SSH 服 务 。 当 连接 上 数据 库 管 理 接 
口 后 ， 便 出 现 “gerrit> ”提示 符 ， 在 该 提示 符 下 可 以 输入 SQL 命令 。 下 
面 的 示例 中 ， 使 用 的 数据 库 的 后 端 为 H2 内 置 数据 库 。 


可 以 输入 show tables 命 令 显 示 数 据 库 列表 。 


gerrit>show tables; 
TABLE_NAME | TABLE_SCHEMA 

和 人 闭关 于 二 站 二 下 
ACCOUNTS|PUBLIC 

ACCOUNT_AGREEMENTS | PUBLIC 
ACCOUNT_DIFF_PREFERENCES | PUBLIC 
ACCOUNT_EXTERNAL_IDS|PUBLIC 
ACCOUNT_GROUPS|PUBLIC 


ACCOUNT_GROUP_AGREEMENTS | PUBLIC 
ACCOUNT_GROUP_MEMBERS | PUBLIC 
ACCOUNT_GROUP_MEMBERS_AUDIT|PUBLIC 
ACCOUNT_GROUP_NAMES | PUBLIC 
ACCOUNT_PATCH_REVIEWS | PUBLIC 
ACCOUNT_PROJECT_WATCHES|PUBLIC 
ACCOUNT_SSH_KEYS|PUBLIC 
APPROVAL_CATEGORIES | PUBLIC 
APPROVAL_CATEGORY_VALUES |PUBLIC 
CHANGES | PUBLIC 
CHANGE_MESSAGES|PUBLIC 
CONTRIBUTOR_AGREEMENTS | PUBLIC 
PATCH_COMMENTS |PUBLIC 
PATCH_SETS|PUBLIC 
PATCH_SET_ANCESTORS |PUBLIC 
PATCH_SET_APPROVALS |PUBLIC 
PROJECTS|PUBLIC 
REF_RIGHTS|PUBLIC 
SCHEMA_VERSION | PUBLIC 
STARRED_CHANGES|PUBLIC 
SYSTEM_CONFIG|PUBLIC 
TRACKING_IDS |PUBLIC 

(27 rows; 65 ms) 


输入 show columns 命 令 显示 数据 库 的 表 结 构 。 


gerrit>show columns from system config; 
FIELD |TYPE |NULL | KEY | DEFAULT 


REGISTER_ EMAIL PRIVATE_KEY |VARCHAR(36)|NO||"! 
SITE_PATH|VARCHAR(255)|YES| |NULL 
ADMIN_GROUP_ID|INTEGER(10)|NO|19 
ANONYMOUS_GROUP_ID|INTEGER(10)|NO|19 
REGISTERED_GROUP_ID|INTEGER(10)|NO|19 
WILD_PROJECT_NAME |VARCHAR(255) |NO||"! 
BATCH_USERS_GROUP_ID|INTEGER(10)1|NO|19 
SINGLETON |VARCHAR(1)|NO|PRI|'"! 

(8 rows; 52 ms) 


关于 H2 数 据 库 更 多 的 SQL 语法 ， 请 参考 : 
http:Wwww.h2database.com/htmlgrammarhtml。 下 面 开 始 介绍 Gerrit 的 


使 用 % 


32.5 “立即 注册 为 Gerrit 管 理 员 


第 一 个 Gerrit 账 户 目 动 成 为 权限 最 高 的 管理 员 ， 因 此 Gerrit 安 逆 完 
毕 后 的 第 一 件 事 情 束 是 立即 注册 或 登录 ， 以 便 初 始 化 管理 员 账号 。 下 
面 的 示例 是 在 本 机 (localhost) 以 HITP 认 证 方式 架设 的 Gerrit 审 核 服务 
器 。 第 一 次 访问 的 时 候 会 弹出 非常 眼熟 的 HTTP Basic Auth 认 证 界面 ， 


如 图 32-4 所 示 。 


图 32-4 HTTP Basic Auth 认证 界面 
输入 正确 的 用 户 名 和 口令 登录 后 ， 系 统 自动 创建 ID 为 1000000 的 账号 ， 该 账号 是 第 一 
个 注册 的 账号 ， 会 被 自动 赋予 管理 员 的 身份 。 因 为 使 用 的 HTTP 认证 ， 用 户 的 邮件 地 址 等 
个 人 信息 尚未 确定 ， 因 此 登录 后 首先 进入 到 个 人 信息 设置 界面 ， 如 图 32-5 
Welcome to Gerrit Code Review 


Please review your contact nformation: 


The followmng contact Informatlon wes automadically obiained when you signed-In to the site. This 
informaticon is used to display who yos are to othars, and to soend updates to code rowaws you have 


either sterted or Subscrmed to 


下 


Pe Br hegater han nail | 


Sove Chengr3 


图 32-5 Gerrit 第 一 次 登录 后 的 个 人 信息 设置 界面 


在 图 32-5 中 可 以 看 到 在 菜单 中 有 “Admin ”菜单 项 ， 说 明 当 前 登录 的 用 户 被 赋予 了 管理 
员 权限 。 在 图 32-5 的 联系 方式 确认 对 话 框 中 有 一 个 注册 新 邮件 地 址 的 按钮 ， 点 击 该 按钮 弹出 
邮件 地 址 录 人 对 话 框 ， 如 图 32-6。 


Register Email Address 


corfirmation link will be sent by email to this address- 


You must clcx on the link to complete the registration and make the address avaliable for selection 


[iangxinemoon.ossxp.com 
Register | Cancel | 


图 32-6 输入 个 人 的 邮件 地 址 


必须 输入 一 个 有 效 的 邮件 地 址 以 便 能 够 收 到 确认 邮件 。 这 个 邮件 地 址 非常 重要 ， 基 
为 Git 代码 提交 时 ， 在 提交 说 明 中 出 现 的 邮件 地 址 需要 和 这 个 地 址 一 致 。 填 写 了 邮件 地 址 


后 会 收 到 一 封 确认 邮件 ， 点 击 邮 件 中 的 确认 链接 会 重新 进入 到 Gerrit 账号 设置 界面 ， 如 图 
32-7。 


Aemis | Documentation 
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图 32-7 邮件 地 址 确认 后 进入 Gerrit 界面 


在 Full Name 字段 输入 用 户 名 ， 点 击 保存 更 改 后 ， 右 上 角 显 示 的 “Anonymous Coward” 
就 会 显示 为 用 户 登录 的 姓名 和 邮件 地 址 : 

接 下 来 需要 做 的 最 重要 的 一 件 事 就 是 配置 公 钥 (如 图 32-8)。 通 过 该 公 钥 ， 注 册 用 户 可 
以 通过 SSH 协议 向 Gerrit 的 Git 服务 器 提交 ， 如 果 具 有 管理 员 权 限 还 能 够 远程 管理 Gerrit 服 
务 器 ， 


32-8 Gerrit 的 SSH 公 钥 设置 界面 


在 文本 框 中 粘贴 公 钥 。 关 于 如 何 生成 和 管理 公 钥 ， 请 参见 “第 29 章 使 用 SSH 协议 ” 
的 相关 内 容 。 

点 击 “Add” 按 钮 ， 完 成 公 和 钥 的 添加 。 添 加 的 公 钥 就 会 显示 在 列表 中 ， 如 图 32-9。 一 个 
用 户 可 以 添加 多 个 公 钥 : 

点 击 左 侧 的 “Groups”( 用 户 组 ) 菜单 项， 可 以 看 到 当前 用 户 所 属 的 分 组 ， 如 图 32-10， 

第 一 个 注册 的 用 户 同时 属于 三 个 用 户 组 ， 一 个 是 管理 员 用 户 组 〔(Administrators)， 另 外 
两 个 分 别 是 Anonymous Users {任何 用 户 ) 和 Registered Users (注册 用 户 ). 
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32-9 ”用 户 的 公 钥 列表 
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图 32-10 Gerrit 用 户 所 属 的 用 户 组 


32.6 ”管理 员 访 问 SSH 的 管理 接口 


在 Gerrit 个 人 配置 界面 中 设置 了 公 钥 之 后 ， 就 可 以 连接 Gerrit 的 SSH 服务 器 执行 命令 ， 
示例 使 用 的 是 本 机 localhost， 其 实 也 可 以 使 用 远程 下 地 址 。 只 是 对 于 远程 主机 需要 了 确认 端口 
不 要 被 防火 墙 拦 截 ，Gerrit 的 SSH 服务 颖 使 用 特殊 的 端口 ， 默 认 是 29418。 

任何 用 户 都 可 以 通过 SSH 连接 执行 gerrit ls-projects 命令 查看 项 目 列表 。 下 面 
的 命令 没有 输出 ， 是 因为 项 目 尚 未 建立 ， 

ss ssh ~P 29418 localhost gerrit ls-proijects 

可 以 执行 scp 命令 从 Gerrit 的 SSH 服务 器 中 拷贝 文件 。 


SS scp -P 29418 -p -r localhost:/ gerrit-files 


SS find gerrit~files -~type 工 


qerrit-files/bin/gqgerrit-cherry-pick 


qerrit-files/hooks,/commit -msq 


可 以 看 出 Gerrit 服务 器 提供 了 两 个 文件 可 以 通过 scp 下载， 其 中 commit-msg 脚本 文件 


应 该 放 在 用 户 本 地 Git 库 的 钧 子 目 录 中 以 便 在 生成 的 提交 中 包含 唯 
一 的 Change-Id。 这 在 之 前 的 Gerrit 原 理 中 介绍 过 。 


除了 普通 用 户 可 以 执行 的 命令 外 ， 管 理 员 还 可 以 通过 SSH 连 接 执 
行 Gerrit 相 关 的 管理 命令 。 例 如 之 前 介绍 的 管理 数据 库 : 


$ssh-p 29418 localhost gerrit gsql 

Welcome to Gerrit Code Review 2.1.5.1 

(H2 1.2.134(2010-04-23)) 

Type '\h' for help.Type '\r' to clear the buffer. 
gerrit> 


此 外 管理 员 还 可 以 通过 SSH 连 接 执 行 账号 创建 ， 项 目 创建 等 管理 
操作 ， 可 以 执行 下 面 的 命令 碍 看 帮助 信息 。 


$ssh-p 29418 localhost gerrit--help 
gerrit COMMAND[ARG...][--][--help(-h)] 
--:end of options 
--help(-h):display this help text 
Available commands of gerrit are: 
approve 

create-account 

create-group 

create-project 

flush-caches 

gsql 

ls-projects 

query 

receive-pack 

replicate 

review 

set-project-parent 

show-caches 

show-connections 

show-queue 

stream-events 

See 'gerrit COMMAND--help' for more information. 


更 多 的 帮助 信息 ， 还 可 以 参考 Gerrit 版 本 库 中 的 帮助 文件 : 


Documentation/cmd-index.html 。 


32.7 ”创建 渐 项 目 


一 个 Gerrit 项 目 对 应 于 一 个 同名 的 Git 库 ， 同 时 拥有 一 套 可 定制 的 
评审 流程 。 创 建 一 个 


新 的 Gerrit 项 目 就 会 在 对 应 的 版 本 库 根 目录 下 创建 Git 库 。 管 理 员 可 以 使 用 命令 行 创建 新 项 目 . 


SS ssh -p 29418 localhost gerrit create-project --name new/project 
执行 gerrit 1s-projects 命令 可 以 看 到 新 项 目 已 经 成 功 创建 。 


号 


$s ssh -p 29418 localhost gerrit ls-projects 
new/proiect 


在 Gerrit 的 Web 管理 界面 也 可 以 看 到 新 项 目 已 经 建立 ， 如 图 32-11， 
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图 32-11 Gerrit 中 项 目 列表 


在 项 目 列表 中 可 以 看 到 除了 新 建 的 newiproject 项目 之 外 还 有 一 个 名 为 “All Projects --” 
的 项 目 ， 其 实 它 并 非 一 个 真实 存在 的 项 目 ， 只 是 为 了 项 目 授权 管理 的 方便 一 一 在 “-- All 
Projects --” 中 建立 的 项 目 授权 能 够 被 其 他 项 目 共 享 ， 

在 服务 器 端 也 可 以 看 到 在 Gerrit 部 署 中， 版 本 库 根 目录 下 已 经 有 同名 的 Git 版 本 库 被 创建 。 


§ ls -d /home/gerrit/review site/git/new/project.git 
/home/gerrit/review site/git/new/project .git 


这 个 新 的 版 本 库 刚刚 初始 化 尚未 包括 任何 数据 ,是 否 可 以 通过 git push 向 该 版 本 库 推 
送 一 些 初始 数据 呢 ? 下 面 用 Gerrit 的 SSH 协议 克隆 读 版 本 库 ， 并 党 试 向 其 推送 数据 。 


$ git clone ssh://localhost:29418/new/project.git myproject 
Cloning into myproject ,.， 
warning: You appear to have cloned an empty repository. 


s cd myproject/ 
8 echo hello > readme .txt 
ss git add readme .txt 


S git commit -m "initialized." 
[master (root-commit} 15a549b] initialized. 
1 files changed, 1 insertions{+}, 0 deletions'(-) 
create mode 100644 readme .txt 
5 git push origin master 
Counting obiects:; 3, done, 
Writing obiects: 100% (3/3), 222 bytes, done. 
Total 3 (delta 0), reused 0 (Gelta 0 
To ssh://localhost:29418/new/proiect .qit 
! [xremore reijected] master -> master (prohibited by Gerrit! 
error: failed to push some refs to ‘ssh://localhost:29418/new/proiect .qit 


向 Gerrit 的 Git 版 本 库 推送 失败 ， 远 程 Git 服务 器 返回 错误 信息 : “prohibited by Gerrit”。 
这 是 因为 Gerrit 默认 不 允许 青 接 向 分 支 推送 ， 而 是 需要 向 refs/for/<branch-name> 的 特 
殊 引 用 进行 推 适 以 便 将 提交 转换 为 评审 任务 ， 

但 是 是 否 可 以 将 版 本 库 的 历史 提交 不 经 审核 ， 直 接 推 送 到 Gerrit 维护 的 Git 版 本 库 中 
呢 ? 是 的 ， 只 要 通过 Gerrit 的 管理 界面 为 该 项 目 授权 : 允许 某 个 用 户 组 (如 Administrators 
组 ) 的 用 户 可 以 直接 向 分 支 推送 。( 注 意 该 授权 在 推送 完毕 后 尽快 撤销 ， 以 免 被 滥用 .) 


Gerrit 的 界面 对 用 户 非常 友好 (如 图 32-12)。 例 如 在 添加 授权 的 界面 中 ， 只 要 在 用 户 组 
的 输入 框 中 输入 前 几 个 字母 ， 就 会 弹出 用 户 组 列表 以 供 选择 。 
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图 32-12 添加 授权 的 界面 


添加 授权 完毕 后 ， 项 目 “newiproject” 的 授权 列表 就 会 出 现 新 增 的 为 Administrators 管 
理 员 添加 的 “+2: Create Branch” 授 权 ， 如 图 32-13， 
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32-13 ”添加 授权 后 的 授权 列表 


因为 已 经 为 管理 员 分 配 了 直接 | 向 refs/heads/* 引 用 推送 的 授权 ， 这 
样 就 能 够 回 Git 版 本 库 推送 数据 了 。 再 执行 一 次 推送 任务 看 看 能 否 成 
功 。 


$git push origin master 

Counting objects:3,done. 

Writing objects:100%(3/3),222 bytes, done. 

Total 3(delta 0),reused 0O(delta 0) 

To ssh://localhost:29418/new/project .git 

![remote rejectedlmaster->master(you are not committer 
jiangxin@ossxp.com) 

error:failed to push some refs to 
'ssh://localhost:29418/new/project.git'" 


推送 又 失败 了 ， 但 是 服务 器 端 返回 的 错误 信息 却 不 同 。 上 一 次 出 
错 返 回 的 是 "prohibited by Gerrit"， 而 这 一 次 返回 的 错误 信息 是 "you are 


not committer" ° 


这 是 为 什么 呢 ? 看 看 提交 日 志 : 


$git 1og--pretty=fu]1 

commit 1i5a549bac6bd03ad36e643984fed554406480b2c 

Author:Jiang Xin<jiangxin@ossxp.com> 

Commit:Jiang Xin<]jiangxin@ossxp.com> 

initialized. 

溃 交 者 Committer 为 "Jiang Xin <jiangxin@ossxp.com >>"， 而 Gerrit 

中 注册 的 用 户 的 邮件 地 址 是 "jiangxin@moon.0ssxp.com"， 两 者 之 间 不 
一 致 ， 导 臻 Gerrit 再 一 次 拒绝 了 提交 。 如 果 再 到 Gerrit 中 看 一 下 


new/project 的 权限 设置 ， 会 看 到 这 样 一 条 授权 : 


Category Group Name Reference Name Permitted Range 


Forge Identity Registered Users refs/*+1:Forge Author Identity 


这 条 授权 的 含义 是 : 提交 中 的 Author 字 段 不 进行 邮件 地 址 是 否 注 
册 的 检查 ， 但 是 要 对 Commit 字 段 进 行 邮件 地 址 检查 。 如 果 增 加 一 个 更 
高 级 别 的 "Forge Identity" 授 权 ， 也 可 以 忽略 对 Committer 的 邮件 地 址 的 
检查 ， 但 是 尽量 不 要 对 授权 进行 非 必 须 的 改动 ， 因 为 在 提交 的 时 候 使 
用 注册 的 邮件 地 址 是 一 个 非常 好 的 实践 。 


下 面 束 通过 git config 命 令 修改 提交 时 所 用 的 邮件 地 址 ， 和 Gerrit 注 
册 时 用 的 地 址 保持 一 致 。 然 后 用 --amend 参 数 重 新 执行 提交 以 便 让 修改 
后 的 提交 者 邮件 地 址 在 提交 中 生效 。 


$git config user.email jiangxin@moon.ossxp.com 
$git commit--amend-m initialized 

[master 82c8fc3]initialized 

Author:Jiang Xin<jiangxin@ossxp.com> 

1 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 readme.txt 

$git push origin master 

Counting objects:3,done. 

Writing objects:100%(3/3),233 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 

To ssh://localhost:29418/new/project .git 

*[new branch]master->master 


看 ， 这 次 提交 成 功 了 ! 之 所 以 成 功 ， 是 因为 提交 者 的 邮件 地 址 更 
改 了 。 看 看 重新 提 区 的 日 志 ， 可 以 发 现 Author 和 Commit 的 邮件 地 址 不 
同 ， 而 Commit 字 段 的 邮件 地 址 和 注册 时 使 用 的 邮件 地 址 相同 。 


$git 1og--pretty=fu]1 

commit 82c8fc3805d57ccod17d58e1452e21428910fd2d 
Author:Jiang Xin<jiangxin@ossxp.com> 

Commit :Jiang Xin<jiangxin@moon.ossxp.com> 
initialized 


注意 ， 版 本 库 初 始 化 完成 之 后 ， 应 尽快 删除 为 项 目 新 增 的 "Push 
Branch" 类 型 的 授权 ， 对 新 的 提交 强制 使 用 Gerrit 的 评审 流程 。 


32.8 从 已 有 的 Git 库 创建 项 目 


如 果 已 经 拥有 很 多 版 本 库 ， 项 望 从 这 些 版 本 库 创 建 Gerrit 项 目 ， 如 
果 像 上 面 介绍 的 那样 一 个 一 个 地 创建 项 目 ， 表 执行 git push 命 令 推送 已 
经 包含 历史 数据 的 版 本 库 ， 将 钙 十 分 矿 烦 的 事情 。 那 么 有 没有 什么 人 简 
单 的 办 法 呢 ? 可 以 通过 下 面 的 步骤 实现 多 项 目的 快速 创建 。 


首先 将 已 有 版 本 库 创 建 到 Gerrit 的 版 本 库 根 目 永 下 。 注 意 版 本 库 名 
称 将 会 成 为 项 目 名 〈 除 去 .git 后 缀 ) ， 而 且 创建 (或 克隆 ) 的 版 本 库 应 
为 梨 版 本 库 ， 即 使 用 --bare 参 数 创建 。 


例如 在 Gerrit 的 Git 版 本 库 根 目录 下 创建 名 为 hello.git 的 版 本 库 。 下 
面 的 示例 中 我 偷 了 一 下 懒 ， 直 接 从 new/project 克 隆 人 到 hello.git 。:) 
$git clone--mirror\ 


/home/gerrit/review site/git/new/project.git\ 
/home/gerrit/review site/git/hello.git 


这 时 查看 版 本 库 列 表 ， 却 看 不 到 新 建立 的 名 为 hello.git 的 Git 库 出 
现在 项 目 列表 中 。 


$ssh-p 29418 localhost gerrit ls-projects 
new/project 


可 以 通过 修改 Gerrit 数 据 库 来 注册 新 项 目 ， 即 连接 到 Gerrit 数 据 
库 ， 输 入 SQL 插入 语句 。 


$ssh-p 29418 localhost gerrit gsql 
Welcome to Gerrit Code Review 2.1.5.1 
(H2 1.2.134(2010-04-23)) 


Type '\h' for help.Type '\r' to clear the buffer. 
gerrit>INSERT INTO projects 


-> (use contributor agreements ,submit type ,name) 
» VALUES 
= (CM' ,MM' ,hello'); 

UPDATE 1; 1 ms 

gerrit> 


注意 SQL 语句 中 的 项 目 名 称 是 版 本 库 名 称 除 去 .9it 后 级 的 部 分 。 在 数据 库 插 和 人 数据 
再 来 查看 项 目 列 表 就 可 以 看 到 新 注册 的 项 目 了 。 

ss ssh -p 29418 localhost gerrit ls-projects 

helioc 


new/proiect 


后 


- 


可 以 登录 到 Gerrit 项 目 对 新 建立 的 项 目 进行 相关 设置 。 例 如 修改 项 目的 说 明 ， 项 目的 提 
交 策 略 ， 是 否 要 求 提交 说 明 中 必须 包含 “Signed-off-by” 信 息 等 ， 如 图 32-14， 
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图 32-14 项 目 基 本 设置 


这 种 通过 修改 数据 库 从 已 有 版 本 库 创 建 项 目的 方法 适合 创建 大 批 基 的 项 目 。 下 面 就 对 新 
建立 的 hello 进行 一 次 完整 的 Gerrit 评审 流程 : 


32.9 ”定义 评审 工作 流 


刚刚 安装 好 的 Gerrit 的 评审 工作 流 并 不 完整 ， 还 不 能 正常 地 开展 评审 工作 ， 需 要 对 项 目 
授权 进行 设置 以 定制 适合 的 评审 工作 流 。 
默认 安装 的 Gerrit 中 只 内 置 了 四 个 用 户 组 ， 如 表 32-1 所 示 ， 


表 32-1 Gerrit 内 置 用户 组 


图 户 组 说 明 

Administrators Gerrit 答 理 吕 

Anonymous Users 任何 用 户 ， 登 录 或 未 登录 
Non-Interactive [lsers Gerrit 中 执行 批 处 理 的 用 户 
Registered Users 任何 登 了 录用 户 


未 登录 的 用 户 只 属于 Anonymous Users， 登 录用 户 则 同时 拥有 
Anonymous Users 和 Registered Users 的 权限 。 对 于 管理 员 则 还 拥有 
Administrators 用 户 组 权限 。 


查看 全 局 ( 伪 项 目 "--All Projects--") 的 初始 权限 设置 ， 会 看 到 如 
表 32-2 一 样 的 授权 表格 。 


表 32-2 Gerrit 授权 表格 


编号 闫 别 用 户 组 名 称 引用 名 称 权限 范围 
-1: | would prefer that you didn*t submit this 
1 Code Revicw Registcred Users refs/hcads/* +l: Looks good to me, but someone clsc 


must approve 


才 Forge ldentity Registcrcd Users refs/* +1: Forge Author Identity 
Read Access Administrators refs/* +l: Read access 
4 Read Access Anonymous Users refs/* +l: Read access 


S$ Read Access Registcred Uscrs refs/* +12: Upload permission 


对 此 表格 中 的 授权 解读 如 下 : 


对 于 匿名 用 户 : 根据 第 4 条 授权 策略 ， 匿 名 用 户 能 够 读 取 任意 版 本 
库 。 


对 于 注册 用 户 : 根据 第 5 条 授权 策略 ， 注 册 用 户 具 有 比 第 四 条 授权 
高 一 个 等 级 的 权限 ， 即 注册 用 户 除 了 有 具有 读 取 版 本 库 权 限 外 ， 还 可 以 
回 版 本 库 的 refs/fov<branch-name> 引 用 推送 ， 产 生 评 审 任 务 的 权限 。 


之 所 以 这 种 可 写 的 权限 也 放 在 "Read Access" 类 别 中 ， 是 因为 Git 的 
写 操 作 必须 建立 在 拥有 读 权 限 之 上 ， 因 此 Gerrit 将 其 与 读 取 都 放 
在 "Read Access" 归 类 之 下 ， 只 不 过 高 一 个 级 别 。 


对 于 注册 用 户 : 根据 第 2 条 授权 策略 ， 在 回 服务 器 推送 所 交 的 时 
候 ， 忽 略 对 提交 中 Author 字 段 的 邮件 地 址 检查 。 这 个 在 之 前 已 经 讨论 
对 于 注册 用 户 : 根据 第 1 条 授权 策略 ， 注 册 用 户 具有 代码 审核 的 一 


般 权 限 ， 即 能 够 将 评审 任务 设置 为 “+1? 级 别 (看 起 来 不 错 ， 但 需要 通 
过 他 人 认可 ) ， 或 者 将 评审 任务 标记 为 “-1” 《评审 任务 没有 通过 不 能 


提交 ) 。 


对 于 管理 员 : 根据 第 3 条 策略 ， 管 理 员 能 够 读 取 任 意 版 本 库 。 


上 面 的 授权 策略 仅仅 对 评审 流程 进行 了 部 分 设置 。 如 : 提交 能 够 
进入 评审 流程 ， 因 为 登录 用 户 (注册 用 户 ) 可 以 将 提交 以 评审 任务 的 
方式 上 传 ， 注册 用 户 可 以 将 评审 任务 标记 为 “+1: 看 起 来 不 错 ， 但 需 其 
他 人 认可 ”。 但 是 没有 人 有 权限 可 以 将 评审 任务 提交 逐一 合并 到 正式 的 
版 本 库 中 ， 即 没 人 能 够 对 评审 任务 做 最 终 的 确认 及 提交 ， 因 此 评审 流 
程 是 不 完整 的 。 


有 两 种 方法 可 以 实现 对 评审 最 终 确 认 的 授权 ， 一 种 是 赋予 特定 用 
户 Verified 类 别 中 的 "+1:Verified" 的 授权 ， 另 外 一 个 方法 是 赋予 特定 用 
户 Code Review 类 别 中 更 高 级 别 的 授权 : "+2:Looks good to 
me,approved"。 要 想 实现 对 经 过 确认 的 评审 任务 的 提交 ， 还 需要 赋予 
特定 用 户 Submit 类 别 中 的 "+1:Submit" 授 权 。 


下 面 的 示例 中 ， 创 建 两 个 新 的 用 户 组 Reviewer 和 Verifier， 并 为 其 
赋予 相应 的 授权 。 


可 以 通过 Web 界面 或 命令 行 创建 用 户 组 。 如 果 通 过 Web 界面 添加 用 户 组 ， 选 择 “Admin” 
菜单 下 的 “Groups” 子 菜单 ， 如 图 32-15， 


Reviewer 


Create Group 


图 32-15 Gerrit 用 户 组 创建 


输入 用 户 组 名 称 后 ， 点 击 “Create Group” 按 钮 ， 进 人 创建 用 户 组 后 的 设置 页 ， 如 图 32-16. 


‘Grmy Chamge #, SHA-Y, trad owner ermall of reviewer em Search) 


Group Reviewer 


| IgEmoon osop com 


Delete | 


32-16 ”Gerrit 用 户 组 设置 页 


注意 到 在 用 户 设 置 页 面 中 有 一 个 Owners 字段 名 称 和 用 户 组 名 称 相 同 ， 实 际 上 这 是 
Gerrit 关于 用 户 组 的 一 个 特别 的 功能 。 一 个 用 户 组 可 以 设置 另外 一 个 用 户 组 为 本 用 户 组 的 
Owners， 属 于 Owners 用 户 组 的 用 户 实际 上 相当 于 本 用 户 组 的 管理 者 ， 可 以 添加 用 户 、 修 改 
用 户 组 名 称 等 。 不 过 一 般 最 常用 的 设置 是 使 用 同名 的 用 户 组 作为 Owners. 

在 用 户 组 设置 页 面 的 最 下 面 ， 是 用 户 组 用 户 分 配对 话 框 ， 可 以 将 用 户 分 配 到 用 户 组 中 。 

32-17 是 添加 了 两 个 新 用 户 组 后 的 用 户 组 列表 ， 


Leerpton 
(EE CartS Adminsaato3 
Snemanavs Waa!s srry Us, $m or nok 
Meleterohe Mers Users who perfarm bah arions en Geant 
gaterea Meat My ined-n ute 
Reaewer 内 有 区 因 让 撤 衣 ES3S5OB 
ia 破 温 主 必 列 这 者 已 


32-17 ”Gerrit 用 户 组 列表 


接 下 来 要 为 新 的 用 户 组 授权 ， 需 要 访问 “Admin” 菜 单 下 的 “Proiects” 子 菜单 ， 点 击 对 
应 的 项 目 进入 权限 编辑 界面 。 为 了 简便 起 见 ， 选 择 “-- All Proiects --"”， 对 其 授权 的 更 改 可 以 
被 其 他 的 所 有 项 目 共享 。 图 32-18 是 为 Reviewer 用 户 组 建立 授权 过 程 的 页 面 。 


Ggs Pro Change 8, SHA-1 Irikt omrer emaf pr reviewer emal searcn| 


Project -- All Projects -- 


Chepoy -Grow fame Peence Nome Form@eg Rnge 


cms 
D CcsRowow RogalatmaUsor hmeaar SILOhs geog mel Sanaine dd meetappre 
口 Forpe cetty Reglzlered Veer mr + 工 Forge Auihorigenkhy 
口 Raw krrest Admnisyzore Bd +1 Rod strcesy 
口 Resd Arcess Ammous Vee mr + 工 Resdg 3FF558 
口 Rewd Arrese Reglslered Ueers misr” 1 Upnajypermssen 


bond sok 


32-18 ”为 Reviewer 用 户 组 建 六 授权 


分 别 为 两 个 新 建立 的 用 户 组 分 配 授权 ， 如 表 32-3 所 示 。 编 号 从 6 开始 ， 是 因为 这 里 补 
充 的 授权 是 建立 在 前 面 的 默认 授权 列表 的 基础 上 的 ， 


表 32-3 新 用 户 组 权限 分 配 表 


编号 类 别 开户 组 名 称 引用 名 称 权限 范 轩 

ey. i 

6 Code Review Reviewer Te 人 /二 ee 
+2: Looks good to me, approved 
-1: Fails 

阳 
Verified Werifier ref + Verified 
8 Snubhmit Werifier T 人 /二 上 1 Siihenil 


这 样 ， 就 为 Gerrit 所 有 的 项 目 设 定 了 可 用 的 评审 工作 流 。 


32.10 ”Gerrit 评 审 工 作 流 实战 


分 别 再 注册 两 个 用 户 账号 dev1@moon.ossxp.com 和 和 
dev2@moon.ossxp.com， 两 个 用 户 分 别 属于 Reviewer 用 户 组 和 Verifier 用 
户 组 。 这 样 Gerrit 部 署 中 就 拥有 了 三 个 用 户 账号 ， 用 账号 jiangxin 进 行 
代码 提交 ， 用 dev1 账 号 对 任务 进行 代码 审核 ， 用 dev2 账 号 对 审核 任务 
进行 最 终 的 确认 。 


32.10.1 开发 者 在 本 地 版 本 库 中 工作 


repo 是 Gerrit 的 最 佳 伴侣 ， 凡 是 需要 和 Gerrit 版 本 库 交 互 的 工作 都 
封装 在 repo 命 令 中 。 关 于 repo 的 用 法 在 上 一 部 分 的 repo 多 版 本 库 协 同 的 
章 世 中 已 经 详细 介绍 了 “。 这 里 只 介绍 开发 者 如 何 只 使 用 git 命 令 来 和 
Gerrit 服 务 器 交互 。 这 样 也 可 以 更 深入 地 理解 rapo 和 Gerrit 整 合 的 机 
制 ， 具 体操 作 过 程 如 下 。 


(1) 首先 克隆 Gerrit 管 理 的 版 本 库 ， 使 用 Gerrit 提 供 的 运行 于 
29418 端 口 的 SSH 协 议 。 


$git clone ssh://localhost:29418/hello.git 
Cloning into hello... 

remote:Counting objects:3,done 
remote:Compressing objects:100%(3/3) 
Receiving objects:100%(3/3),done. 


(2) 然后 拷贝 Gerrit 服 务 器 提供 的 commit-msg 钧 子 脚 本 。 


$cd hello 
$scp-P 29418-p localhost:/hooks/commit-msg.git/hooks/ 


(3) 别 筷 了 修改 Git 配 置 中 提交 者 的 邮件 地 址 ， 以 便 和 Gerrit 中 注 
册 的 地 址 保持 一 致 。 不 使 用 --global 参 数 调用 git config 可 以 只 对 本 版 本 
库 的 提交 设 定 提交 者 邮件 。 


$git config user.email jiangxin@moon.ossxp.com 


(4) 然后 修改 readme.txt 文 件 并 提交 。 注 意 提交 的 时 候 使 用 了 "- 
s" 人 参数 ， 目 的 是 在 提交 说 明 中 加 入 "Signed-off-by:" 标 记 ， 这 在 Gerrit 提 


$echo "gerrit review test" > >readme ,txXt 

$git commit-a-s-m "readme.txt hacked." 

[master c65ab49]readme.txt hacked. 

1 files changed,1 insertions(+),0 deletions(-) 


(5) 查看 一 下 提交 日 志 ， 会 看 到 其 中 有 特殊 的 标签 。 


$git lo0g--pretty=full-1 

commit c65ab490f6d3dc36429b8f1363b6191357202f2e 
Author:Jiang Xin<jiangxin@moon.ossxp.com> 

Date:Mon Nov 15 17:50:08 2010+0800 

readme.txt hacked. 
change-Id:Id7c9d88ebf5dac2d19a7e0896289de1ae6fb6a90 
Signed-off-by:Jiang Xin<jiangxin@moon.ossxp.com> 


提交 说 明 中 出 现 了 "Change-Id:" 标 签 ， 这 个 标签 是 由 钩子 脚 
本 "commit-msg" 目 动 生 成 的 。 至 于 这 个 标签 的 含义 ， 在 前 面 Gerrit 的 实 
现 原理 中 已 经 介绍 过 。 


好 了 ， 准 备 把 这 个 提交 推送 到 服务 器 上 吧 。 


Pd 


32.10.2 ”开发 者 问 审 核 服 务 紫 提交 


由 Gerrit 控 制 的 Git 版 本 库 不 能 直接 提交 ， 因 为 正确 设置 的 Gerrit 服 
务 器 ， 会 拒绝 用 户 直 接 向 refs/heads/* 推 送 。 


$git status 

#0n branch master 

#Your branch is ahead of 'origin/master' by 1 commit. 

# 

nothing to commit(working directory clean) 

$git push 

Counting objects:5, done. 

Writing objects:100%(3/3),332 bytes, done. 

Total 3(delta 0),reused 0O(delta 0) 

To ssh://localhost:29418/hello.git 

![remote rejectedlmaster->master(prohibited by Gerrit) 

error:failed to push some refs to 
'ssh://localhost:29418/hello.git' 


直接 推送 束 会 过 到 "prohibited by Gerrit" 的 错误 。 


正确 的 做 法 是 向 特殊 的 引用 推送 ， 这 样 Gerrit 会 自动 将 新 提交 转换 
为 评审 任务 。 


$git push origin HEAD:refs/for/master 
Counting objects:5, done. 

Writing objects:100%(3/3),332 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 

To ssh://localhost:29418/hello.git 

*[new branch]HEAD- >refs/for/master 


看 到了 上 吗 ， 疝 refs/for/master 推 送 成 功 。 


32.10.3 ”审核 评审 任务 
以 Dev1 用 户 登 录 Gerrit 网 站 ， 点 击 "All" 羔 单 下 的 "Open" 标 签 ， 可 
以 看 到 新 提交 到 Gerit 的 状态 为 Open 的 评审 任务 ， 如 图 32-19。 


间 | Wy | Admin | Documemtation | Devi <dev oon.o55xp.com> 
Open Merged Abandoned sts -OPEN 


Search for status:open 


Un Subject Owner 
pb” Igrcodise readmebihacked Jiang mn helo 


图 32-19 Gerrit 评审 任务 列表 


点 击 该 评审 任务 ， 显 示 关 于 此 评审 任务 的 详细 信息 ， 如 图 32-20。 


日， 


Change 1d7<9dB5er reedrrie Ext hacked. | Iocalhest Code Review - ICeweasel 


文 林 {E) 坟 和 全 二 看 Y) 代 史 (5) 书 六) 新 分 E) 工具 (下 坟 电 ) 
tpsWocahostgemtiwchangel 全 罗 vj 
| es 8 后: 


Change ld7c9d88e': readme.txt hacked. 


Changerjd le7cads8ebf5aac2d19a7ec69a759de1aebbtagn 加 


readme ,xxt hacked, 


Change-Id: Id7c9ds5ebf5dac2d19a7e0896289de1ae6fb6aa 
Stoned-off-by: Jiang Xin <]ianOx1nemoon .ossxp.com> 
aaey Now 15, 2010 506 FM 
Unpaid Nor 15, 2010508 PM 

Statis Review In Proyress 


Pamaink 加 
» NeedVermed *T (Verbed) 
» Need Code Review *2 (Lo0ks 900d 10 me, approved) 


[Name or Email Add | 


bP Dependencies 
VW patch Sot 1 c655abd4o065d3dc35429bafl363b6191357202Pe [ghwsb) 
Di JannXin “jangiin@moon. orp com> Now 15, 2010 .50 PM 


Commewer Ja “iongin@rmoon. ossp om Noy15， A 
Checkoef [ol 


s HTTP 隔 
fg1t fetch hrtps: /1ocal host/ oer 17heTTe Tr aa gir checkout FETCH_HES 


32-20 Gerrit 评审 任务 概述 
从 URL 地 址 栏 可 以 看 到 该 评审 任务 的 评审 编号 为 1。 目 前 该 评审 任务 有 一 个 补丁 集 


(Patch Set 1)， 可 以 点 击 “Diff All Side-by-Side” 查看 变更 集 ， 以 决定 该 提交 是 否 应 该 被 接 
受 。 作 为 测试 ， 先 让 此 次 提交 通过 代码 审核 ， 于 是 以 Devl 用 户 身份 点 击 “Review” 按 钮 
点 击 “Review” 按 钮 后 ， 弹 出 代码 评审 对 话 杠 ， 如 图 32-21. 


Change-1d: jdycqcs3pbf5cac2d19n700896259tdeluAeo6fE6a3o 
Stonod-off-by: Jiang Xin <]jiangx1ngroon.055xpD_Corty 


图 32-21 ”Gerrit 任务 评审 对 话 框 


选择 “+2; Looks good to me, approved.”， 点 击 按钮 “Publish Comments” 以 通过 评审 ， 
注意 因为 没有 给 Devl 用 户 (Reviewer 用 户 组 ) 授予 Submit 权限 ， 因 此 此 时 Dev1 还 不 能 将 
此 审核 任务 提交 。 

Dev1 用 户 做 出 通过 评审 的 决定 后 ， 代 码 提交 者 jiangxin 会 收 到 一 封 邮件 ， 如 图 32-22。 


Cooments on Patch Set 1; 
Patch Set 1: Looks good to me, approved 
To respond, visit hitps://localhost/gearrit/l 


To View Visit ltansii/loralhost/oerrir/l 
To unsubscribe, visat httnss//iccalhost/oerrit/settings 


Gerrit-MessageType: Compent 

Gerrit-Project: hetlo 

Gerrit-Branchr paster 

Gerrit-Duner; Jiang Xin SR09XinGtaQnL ne5xp. Sana> 
Gorrit-Raviewar; Devi < 


图 32-22 ”Gerrit 通 知 邮件 


32.10.4 评审 任务 没有 通过 测试 


下 面 以 Dev2 账号 登录 Gerrit， 查 看 处 于 打开 状态 的 评审 任务 ， 如 图 32-23。 会 看 到 评审 
任务 1 的 代码 评审 已 经 通过 ， 但 是 尚未 进行 测试 检查 (Verify)。 于 是 Dev2 下 载 该 补丁 集 ， 
在 本 机 进行 测试 。 


Admin | Documenmation Develo <d 
Coen Merged  #bandoned statys open 


Change lId7c9d88e: readme.txt hacked. 


Change-[ 愉 1d7csdeBeb45dac2d19a7e0692259de1aebrb6a90 一 readme .txt hacked. 


Owner Jiang Mn 
Pest bala change-Id: Id7c3d8Bebf5dac2d19a780856285delae5fb6a5 
CA master Sioned-off-by: Jiang Xin <jiangxinGnoon .055SXP -ComoD 
Teng 
Upbaged Nov15 2010 6:08 PWM 
Upoated Nor15, 2010 6:27 PM 
SU5 Roview In Progress 
P nk 大 


Vertiag Co Ravi 
Revl WY Looks 000d $0 me, approved 


。 NeogdVverned + (verfied) 
[Name or Email Add Ranawer ， 


> Dependencies 
Y Palch Set1 5c553b4905d9dc36429b9fl3635191357202Re [citweb) 


有 Se JangqXin<llangdnErnoon os com> Nov 15, 2010 $50 PN 
Co ,Jiang in « bt ee 03s%0 C0m> ov 15, et 50 PM 
UL hn 0 


Ea SSH | HTTP 
gir ferch -ss CCa hostoenrTE meio refs/Changes/0OL/1A 8 girt checkoug FETCH_HE 


DiAlSide-by-Sige| -DifAluniped | 


32-23 ”Gerrit 评 审 任务 显示 


假设 测试 没有 通过 ，Dev2 用 户 点 击 该 评审 任务 的 "Review" 按 钮 ， 
重 置 该 任务 的 评审 状态 ， 如 图 32-24 。 


Ml | My | Atmin | Documentakion Developer2 <da 
Qpan Merned 此 andonad 


Change ld7c9d88e - Patch Set 1; Publish Comments 


xd7Tcodmsbtydec2d19974085D09de1acffhr30 加 Feadaa:tt ackaed: 


Change 1d; Pte est dac2 hid e0962 rg 
Signed-o 


Or Locks gond to me bul scrmeone se must spproww 
2\ 

(% 0 Ne soore 

OO -teowud srefer Hal yo del sut oR pis 


Coves lessage- 


一 一 


Pyubish Comments Pupish and Submit Cancel 


32-24 ” Gerrit 评审 任务 未 通过 


主意 到 图 32-24 中 Dev2 用 户 的 评审 对 话 框 有 三 个 按钮 ， 多 出 
的 "Publish and Submit" 按 钮 是 因为 Dev2 拥 有 Submit 授 权 。Dev2 用 户 在 
上 面 的 对 话 框 中 选择 了 "-1:Fails"， 点 击 "Publish Comments" 按 钮 ， 该 评 
审 任务 的 评审 记录 被 重 置 ， 同 时 提交 者 和 其 他 评审 参与 者 会 收 到 通知 
邮件 ， 如 图 32-25 。 


Comments on Patch Set 1: 
Patch Set 1: Fails 


To respond, visit https://localhost/oerrit/} 


To view Visit 


httos://localhost/oorrit/l 
To unsubscribe, visit https://localhost/gerrit/settings 


Gerrit-MessageType: conpent 

Gerrit-Project: hello 

Gerrit-Branch; master 

Gerrit-Owner: 了 af Xin <iangxinanonn, osxp, Cos> 
Gerrit-Reyiewer’; Devl <devlpoon ossxp. con> 
Gerrit-Reviewer; Deaveloper2 <dev2fmoon. 055xD .CoB> 


图 32-25 ”Gerrit 通 知 邮件 ， 评审 未 通过 


32.10.5 ”重新 提交 新 的 补丁 集 


提交 者 收 到 代码 被 打 回 的 邮件 ， 一 定 很 难过 。 不 过 这 恰恰 说 明了 
这 个 软件 过 程 已 经 相当 的 完善 ， 现 在 发 现 问题 总 比 在 集成 测试 时 甚至 
被 客户 发 现 要 好 得 多 吧 。 


根据 评审 者 和 检验 者 的 提示 ， 开 发 者 对 代码 进行 重新 修改 。 下 面 
的 Bugfix 过 程 仅仅 是 一 个 简单 的 示例 ，Bugfix 没 有 这 么 人 简单 的 ， 对 
吗 ? ;-) 


$echo "fixed"> >readme .txt 


重新 修改 后 ， 需 要 使 用 --amend 参 数 进行 提交 ， 即 使 用 前 次 提交 的 
日 志 重 新 提交 ， 这 一 点 非常 重要 。 因 为 这 样 就 会 对 原 提 区 说 明 中 
的 "Change-Id:" 标 等 予以 原样 保留 ， 当 再 将 新 提交 推送 到 服务 融 时 ， 
Gerrit 不 会 为 狐 提 有 交 生 成 新 的 评审 任务 编号 ， 而 古 重用 原 有 的 任务 编 
号 ， 将 新 提交 转化 为 老 评审 任务 的 狐 补 本 集 ， 具 体操 作 过 程 如 下 。 


(1) 在 执行 git commit--amend 时 ， 可 以 修改 提交 说 明 ， 但 是 注意 
不 要 删除 Change-Id 标 签 ， 更 不 能 修改 它 。 


$git add-u 

$git commit--amend 

readme .txt hacked with bugfix. 
Change-Id:Id7c9d88ebf5dac2d19a7e0896289de1ae6fb6a90 


Signed-off-by:Jiang Xin<jiangxin@moon.ossxp.com> 

#Please enter the commit message for your changes.Lines starting 

#with '#' will be ignored,and an empty message aborts the 
commit. 

#0n branch master 

#Your branch is ahead of 'origin/master' by 1 commit. 

# 

#Changes to be committed: 


#(USe "git reset HEAD^1<file>..."to unstage) 
# 

#modified:readme ,txt 

## 


(2) 提交 成 功 后 ， 执 行 git ls-remote 命 令 会 看 到 Gerrit 维 护 的 Git 库 
中 只 有 一 个 评审 任务 〈 编 号 1) ， 且 该 评审 任务 只 有 一 个 补丁 集 
(Patch Set 1) 。 
$git ls-remote origin 
82c8fc3805d57ccod17d58e1452e21428910fd2d HEAD 


c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
82c8fc3805d57ccod17d58e1452e21428910fd2d refs/heads/master 


(3) 把 修改 后 的 提交 推送 到 Gerrit 管 理 下 的 Git 版 本 库 中 。 注 意 依 
上 日 推送 到 refs/forvmaster 引 用 中 。 


$git push origin HEAD:refs/for/master 
Counting objects:5, done. 

Writing objects:100%(3/3),353 bytes, done. 
Total 3(delta 0),reused 0O(delta 0) 

To ssh://localhost:29418/hello.git 

*[new branch]HEAD- >refs/for/master 


(4) 推送 成 功 后 ， 再 执行 git ls-remote 命 令 ， 会 看 到 唯一 的 评审 
任务 (编号 1) 有 了 两 个 补丁 集 。 


$git ls-remote origin 
82c8fc3805d57ccod17d58e1452e21428910fd2d HEAD 
c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/changes/01/1/2 
82c8fc3805d57cc0d17d58e1452e21428910fd2d refs/heads/master 


32.10.6 ”新 修订 集 通 过 评审 


当 提 交 者 重新 针对 评审 任务 进行 提交 时 ， 原 评审 任务 的 审核 者 会 
收 到 通知 邮件 ， 提 醒 有 新 的 补丁 集 等 竺 评审 ， 如 图 32-26 。 


发 从 和 jiang Xin (Code Reviewj <gerrit@localhost> 六 
皮 用 [master] Change 1d7c9d88e: (hello) readme,txt hacked. 
回复 至 jiangxin@moon.ossxp com 5 
收 凡 人 Developer2 <dev2@moon.ossxp com> 00, Devi <devl@moon ossxp.com> 
Hello Developer2, Dev]l, 


i'd like you to reexanine change Id7c9d83e. 
Change Id7c9d98e (patch set 2) for naster in hello: 


readme. txt hacked with bugfix. 


Change-1d: mi rte toga rdire pctgp ter 


ON "off-by: Jiang Xin <jiangx 


readae: txt 
1 file changed, 2 insertions[+), © deteticnst -)} 


git putt ssh://localhost:;29419/hellto refs/changes/01/1/2 


Gerrit- Mes we hy Type newputchset 
Gerr ; hello 
Gerrit， Branch: gaster 

erit- Ouner: Jiang Xin <Tiangxinenec 
Gerrit-Reyiewer: Devl 
Gerrit-Revlewer: Developer2 < 
Gerrit-Reviewer: J1ang Xin < 


图 32-26 Gerrit 通知 邮件 : 新 补丁 集 
登录 Gerrit 的 Web 界面 ， 可 以 看 到 评审 任务 1 有 了 新 的 补丁 集 ， 如 图 32-27 所 示 。 


J 
Dayeioner? XX 


sa NeedVenfied +1 (Verfied} 
sa NeedCode Fovigw +7 (Looks go0d to ms, apperom) 


[Name oF Ermail Add Reviewer | 


# patch Set1 055ab43064d3d035429b6f136306191357202Ce [oitwab) 
Y patchSet2 1 吧 eBe05fcp7a465334885919a476abdidB121 tlwsal 


hor Jiar yz -llangyjngrmoon.035yp com> Nov15, 2010 5.50 PM 
CO ang yn jianogrin@rmnoon 0s com> Now 15, 2010703 PM 
chxetknut | pull } eherry pk | pseh | EE! Se9H LHP = = dl 
Downtoed git fetch ssh://dev2Qiocalhost:29418/hello refs/changes/01/1/2 é&& git checkout FETCH_HE 


Revew | DiftAlSide-by-Sice Df Alunifed | 
Comments 


图 32-27 Gerrit 新 补丁 集 显示 


再 经 过 代码 审 枝 和 调试 ， 这 次 Dev2 用 户 决定 让 评审 通过 ， 点 击 了 “Publish and Submit” 
按钮 。Submit (提交 ) 动作 会 将 评审 任务 (refs/changes/01/11i2) 合并 到 对 应 分 支 (master) 
中 。 图 32-28 显示 的 是 通过 评审 完成 合并 的 评审 任务 1， 


Developer2 < 


Change #. SHA-1, rid. OwnNer ®nal of rewewer emall 


| My | Mdmin | Doeunvetaton | 2 
hanaes Drafs Yostched Changes Storred Ghanaes 


Change ld7c9d88e: readme.txt hacked with bugfix. 


Cronpe-io 1d7c9dttmbf3caczd19a7e08920sdetaetmi90 加 readne ,txt hacked with bugfix, 
‘Owner dang Xi 
Frojec! hall Change-1d: Id7c9dsaebfSsdac2d19a7e0896259delae6fb65a9) 
Bamh measier Signed-off-by: Jiang Xin <jiangxinGmoon.o5sxp.com> 


Gn Nowt5, 20106:08 Pw 
RE Nov 15.2010714 PW 
Status Merged 


Parmaink 国 
Reviewes Vented Co Review 
rn 
Davi a Looks 00d to me, approved 
Devwiooer a Venfieé 
条 Inctudesd in 
> Dependencies 


bP patehSe1 "65ab490D6d3dc35429b8t1363b6151357202Re (tanb) 
VpatchSe2 。 1dgsBs05fc97a46586463916a4753abd1d5121 (gitwab) 


32-28 ”Gerrit 合 并 后 的 评审 任务 


32.10.7 ”从 远程 版 本 库 更 新 


当 Devl 和 Dev2 用 户 完成 代码 评审 后 ， 提 交 者 会 收 到 多 封 通知 邮件 。 这 其 中 最 让 人 激动 的 
就 是 代码 被 接受 并 合并 到 开发 主线 (master) 中 ， 如 图 32-29 所 示 ， 这 令 开 发 者 感到 多 么 荣 粮 啊 。 


和 Daveloper2 (Code Review}) <gerrt@localhost> 
[mester] Change ld7c9dBse: (hello) readme.txt hacked with bugfix. 


让 复 至 dav2@moon ossxp, com 
以 仓 人 Jang Xin <jiangxin@moon.ossxp com> 
WE Devl <devlG@hin0on.655z com> 


Change Id7c3dbge by Jiang Xin subaitted to aaster; 
Feadae.txt hacked with bugfix 


Chang9e-Id: Id7c9d68ebf5dac2dg19a7e6896289delae6 他 5896 
Signed-off-by; Jiang Kin <jiangxlinenoon, as5xn oa> 


MH rendne, txt 
1 file changed, 2 insorticns(+}, 0 dolotions(-) 


Approvals 
Developer2: Verified 
Devl: Looks good to me, approved 


图 32-29 Gerrit 通知 邮件 : 修订 已 合并 


代码 提交 者 执行 git pul， 和 Gerrit 管 理 的 版 本 库 同步 。 


$git ls-remote origin 
ilidf9e8e05fcf97a46588488918a476abd1idf8121 HEAD 
c65ab490f6d3dc36429b8f1363b6191357202f2e refs/changes/01/1/1 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/changes/01/1/2 
1df9e8e05fcf97a46588488918a476abd1df8121 refs/heads/master 
$git pull 

From ssh://localhost:29418/hello 

82c8fc3..1df9e8e master->origin/master 

Already up-to-date. 


32.11 更 多 Gerrit 人 参考 


Gerrit 涉 及 的 内 容 非 常 庞 杂 ， 还 有 诸如 和 Gitweb、git-daemon 整 
合 ，Gerrit 界 面 定制 等 功能 ， 怨 不 在 此 一 一 列举 。 可 以 直接 参考 Gerrit 
网 站 上 的 帮助 加 。 


[1| http://gerrit.googlecode.com/svn/documentation/ 


第 33 章 ”Git 版 本 库 托 管 


想 不 想 在 互联 网 上 为 自己 的 Git 版 本 库 建立 一 个 克隆 ? 这 样 就 再 也 不 必 为 数据 的 安全 担 
忧 (异地 备份 ，， 还 可 以 和 他 人 共享 数据 、 协 同 工 作 ? 但 是 这 样 做 会 不 会 很 贵 呢 ? 比如 要 购 
买 域名 、 虚 执 主 机 、 搭 建 Git 服务 器 什么 的 ? 

实际 上 可 以 免费 获得 这 种 服务 (Git 版 本 库 托管 服务 ) ! GitHub、Gitorious 等 都 可 以 锡 
费 提 供 这 些 服 务 ， 


33.1 Github 


如 果 您 是 按部就班 式 地 阅读 本 书 ， 那 么 可 能 早 就 注意 到 本 书 的 很 多 示例 版 本 库 都 是 放 在 
GitHub 上 的 。GitHub 提供 了 Git 版 本 库 托管 服务 ， 琶 包括 收费 的 商业 支持 ， 也 提供 免费 的 
服务 ， 很 多 开源 项 目 把 版 本 库 直接 放 在 了 GitHub 上 ， 如 : jQuery、curl、Ruby on Rails 等 。 

注册 一 个 GitHub 账号 非常 简单 ， 访 问 GitHub 网 站 : hipsiWgithub.com/， 点 击 菜 单 中 的 
“Pricing and Signup” 就 可 以 看 到 GitHub 的 服务 列表 (如 图 33-1)。 会 看 到 其 中 有 一 个 免费 
的 服务 :“Free for open souree”， 并 且 版 本 库 托管 的 数 基 不 受 限 制 。 当 然 免 费 的 午餐 是 不 管 
饱 的 ， 托 管 的 空间 只 有 300MB， 而 且 不 能 创建 私有 版 本 库 。 


github Home ProngavsSigmup Training Gis!t Blog Login 


Plans & Pricing 


Jonm today and oolinborale wWih the smarlest deveiopers n he World 


50 Free for open source i i 
Uniamiied pubic repoanees nd onlimited pubhc colabomos 了 


Micro $7m Small $12m Medium $22mo 
5Private Repositories : 10 Private Hepositories 20 Private Reposilories 
1 Private Collaborator 5Private Collsborators 10Private 

Unllmited pudbe repostories Untimited pubic repospones Unlimied Public reposilorle5 


‘Unlimited PuUblo cclaborsicrs Unilmited pubic coliabpralors Unlimiied publlo oolaborotors 


图 33-1 GitHub 服务 价目 起 
点 击 按钮 “Create a free account"”， 就 可 以 创建 一 个 免费 的 账号 。GitHub 的 用 法 和 前 面 


介绍 的 Gerrit Web 界面 的 用 法 很 类 似 ， 一旦 账号 创建 ， 应 该 马上 为 新 建立 的 账号 设置 公 和 乌 ， 
以 便 能 够 用 SSH 协议 读 写 自己 帐号 下 创建 的 版 本 库 ， 如 图 33-2 所 示 ， 


LS 好 拓 站 心 - 免 绒 及 汁 对 套餐 人 组 织 


至 少 需 要 一 条 3SH 公 铀 ， 你 才 赂 推送 git 他 第 到 GItHub。 


Free DO0 O00 0.00GB/0.30GB 
前 取 有 个 奈 私有 协作 青 实在 衬 加 1 坎 限 着 
入 下 于 要 2 
太 我 们 9b 公 局 夫 份 请 同 g 项 目 企 订 
公开 树 案 至 少 震 要 一 亲 SSH 公 己 ， 你 才能 推送 9it 仓库 到 GilHub。 的 极限 。 需要 有 关公 钠 的 冲销 色 ? 
账户 管理 标题 
电子 组 特地 址 | = 
SSH 公 钙 320-xz38 AIABSSHzariYC2EAAAADAOABAAABAGCoB7E 
TT TN PLUGECDCCS 
求 阴 村 两 JPME Sn SCRY re DC Yupt] 
LSSRee tallpSI LeontID Ce :arooliyscHEPAC S32DI 
+HcsC TC Un tztyp TiN ome lS+ shh? emdarb| 


QMmxDptqcichdrgr decDy sp Ia pg 
cmoslphvooletyl Tht i Tobe rE CIn?7 EsTO+ rese GC At 采 


娘 加 公 人 情 cf 可 消 
图 33-2” GitHub 上 配置 公 铀 


创建 仓库 的 操作 非常 简单 ， 首 先 点 击 菜单 上 的 “主页 ”(Dashboard)， 再 点 击 右 侧 边 栏 上 
的 “新 建仓 库 ” 按钮 就 可 以 创建 新 的 版 本 库 了 ， 如 图 33-3 所 示 。 


github ES ,mexun E30 
COOING 过 本 Nub G4 生计 诈 队 “有 辐 1Q Seu Gtb 


加 你 秆 ,jg You can use git oat -interactive to stage part of you’ working copy for commil LE 
新 闻 订 税源 。” 俯 的 动作 清 求 汰 隘 人 急 析 入 角 
足 家 得 米 到 | GitHub ! 换 下 米 该 佑 什么 ? LO 17T 3019 


Create a fiopostery 你 的 仓库 (1) EZED 
Tal us adout youLrseil 


Browse Intereshng Repos a l 
Leam more about Si and Gitriubh a 公开 “各 有 和 W WE 


BB jiangnrfreesmind-menx 


图 33-3 GitHub 页 面 上 的 新 建 版 本 康 按 钮 
新 建 版 本 库 会 浪费 本 来 就 不 多 的 托管 空间 ， 从 GitHub 上 已 有 的 版 本 库 派 生 (fork) 一 个 
克 降 是 一 个 好 办 法 。 首 先 通过 GitHub 搜索 版 本 库 名 称 ， 找 到 后 点 击 “ 派 生 ” 按 钮 ， 就 可 以 
在 自己 的 托管 空间 内 建立 相应 版 本 库 的 克隆 ， 如 图 33-4 所 示 ， 


计 | b 加 jangxin 主人 改作 厅 诅 帐户 语 浸出 | 
gitNnUuD 拳 索 GifHub ”GIs1 ” 情 嘲 。 攻 盖 人 


© {Q Sewch GrHus 


时 Ossxp-Com / repo 本 关注 及 村 本 中 1 1 


| 源 代码 “提交 。 谋生 网 络 。 抓获 迹 救 (中 作 务 单位 希 表 ， 
妇 禾 分 训 [II * 。_ 缠 拷 样 每 6D * 。 介 友 列表 


er 


Andirotd repo wolhks witiout review server 
性 下 载 
me ornw St bob. conorp"con/ rupo. Net 本 反 URL 为 内 洁 


图 33-4 自 GitHub 上 的 版 本 库 派 全 


版 本 库 建立 后 就 可 以 用 Git 命令 访问 GitHub 上 托管 的 版 本 库 了 。GitHub 提供 三 种 协议 
可 供 访 问 ， 如 图 33-5 所 示 。 其 中 SSH 协议 和 HTTP 协议 支持 读 写 ，Git-daemon 提供 只 读 访 
问 。 对 于 自己 的 版 本 库 当 然 选择 支持 读 写 的 服务 方式 了 ， 其 中 SSH 协议 是 首选 。 


gil | 高 liangxin 主页 尼 作 和 加 坚 户 设置 。 这 出 


天 术 Oilub Gist 特 看 WD ©/ Search Guo 


i 
半 活生生 “repo ， 信念 理 机 二 取 清关 乌 看 沽 全 让 天 汶 近 了 人命 1 A442 
埋 代 码 。 如 交 。 浙 生 网 络 。 寿 肥 请 求 的 诬 生 处理 队 列 。 维基 (0 。 型 表 吧 :raater 
所 技 出 支 11) ”说 热 林 失 由 游 * 和 苏 变 列 条 
Androld Re ey without review server tl 下 载 
点 击 泪 时 深 加 主 页 区 外 
a me enn mmr ee hn 
repo push shouldn'c push to tags. 2 
于 omf 让 TTTdYIpTd3AG61 
jangxin Taumocn 人 
已 cober 28, 2040 


图 33-5 版 本 库 访问 URL 


33.2 Gitorious 


Gitorious 是 另外 一 个 Git 版 本 库 托管 提 供 商 ， 网 址 为 http://gitoricous.orgi， 
如 图 33-6 所 示 。 最 酷 的 是 Gitorious 本 身 铭 架 站 软件 也 是 开源 的 ， 可 以 通过 Gitorious 上 的 
Gitorious 项 目 访问 。 如 果 你 熟悉 Ruby on Rails， 可 以 架设 一 个 本 地 的 Gitorious 服务 


Sitorious - OItornious - Keweerel 
文 忻 人 E》 态 鲁 优生 大 (YX》 应 史 | 委 | 己基 (| 新 分 P) 工 AQG) 帮 MIM) 
介 写 vO mt oronovs orgfytonous * go0%e opelv 


wh Gitorous ~ GEoNous |* 


| -Series 


Gitorious 


LU Openwit 


Profeect intormation 
mainline Labels 


Ne x Licerrmes 
“0 Cie Kk posh tp OO 已 


94 .Blcnous crpgioncuamartns gt Cwner 
Cee3fed 
Ceommit og 为 和 oerss iree 2 Wree rmqmsis /可 D Ciore regonitory Wiatce Weba ol 


Weallinglist of 


可 Fonyemxy 站 用 各 讲台 六 让 0 $C 


33-6 ”Gitorious 上 的 Gitorious 项 目 


第 6 篇 “迁移 到 Giit 


随 看 Git 版 本 控制 系统 的 成 熟 ， 越 来 越 多 的 项 目 把 版 本 控制 系统 迁 
移 到 了 Git 上 “。 迁 移 大 多 是 无 损 的 ， 即 迁移 到 Git 后 完美 地 保留 了 之 前 
的 变更 历史 、 分 文 和 里 程 碑 。 如 有 果 你 正 打算 迁移 版 本 控制 系统 ， 本 篇 
介绍 的 版 本 库 迁 移 方法 和 注意 事项 将 会 为 你 提供 帮助 。 


本 篇 首先 会 介绍 CVS、Subversion、IMercurial 等 几 个 著名 的 开源 版 
本 控制 系统 如 何 迁 移 到 Git 上。 除 这 些 之 外 的 其 他 版 本 控制 系统 也 许可 
以 找到 类 似 的 迁移 方案 ， 或 者 可 以 针对 git-fast-import 通 过 编程 的 方式 
定制 转换 过 程 。 在 本 篇 的 最 后 ， 还 会 介绍 一 个 让 Git 版 本 库 改 头 换 面 的 
更 为 强大 的 工具 git-filter-branch 。 


第 34 章 CVS 有 版 本 库 惠 Git 的 迁移 


CVS 是 最 早 被 广泛 使 用 的 版 本 控制 系统 ， 因 为 其 服务 右 端 的 存储 
结构 非常 简单 ， 至 今 仍 受到 不 少 粉 丝 的 钟爱 。 但 是 ， 它 毕竟 是 几 十 年 
前 的 产物 ， 因 为 设计 上 的 原因 ， 导 致 其 缺乏 现代 版 本 控制 系统 的 一 些 
必 备 的 功能 ， 如 : 没有 原子 提交 、 分 支管 理 不 便 ( 慢 ) 、 分 支 合并 困 
难 (因为 合并 过 程 缺 乏 跟踪 ) 、 不 支持 文件 名 /目录 名 的 修改 ， 等 等 。 
CVS 的 很 多 用 户 都 已 经 迁移 到 Subversion 这 一 更 好 的 集中 式 版 本 控制 系 
统 了 。 如 果 你 还 在 使 用 CVS， 那 么 可 以 考虑 直接 迁移 到 Git 。 


从 CVS 迁 移 到 Git 可 以 使 用 cvs2svn 软 件 包 中 的 cvs2git 命 令 。 为 什么 
该 项 目的 名 称 是 cvs2svn 而 非 cvs2git 呢 ? 这 是 因为 该 项 目 最 早 是 为 CVS 
版 本 库 迁 移 到 Subversion 版 本 库 服务 的 ， 只 是 最 近 才 增加 了 CVS 版 本 库 
转换 为 Git 版 本 库 的 功能 。cvs2svn 将 CVS 转 换 为 Subversion 版 本 库 的 过 
程 一 直 以 稳定 著称 ， 从 cvs2svn 2.1 版 开始 ， 增 加 了 将 CVS 版 本 库 转 换 
为 Git 版 本 库 的 功能 ， 这 无 颖 让 这 个 工具 更 具 和 生命力 ， 也 减少 了 之 前 
CVS 到 Git 库 的 转换 环节 。 在 推出 cvs2git 功 能 之 前 ，CVS 迁 移 到 Git 的 路 
径 通常 是 : 先 用 cvs2svn 将 CVS 版 本 库 迁 移 到 Subversion 版 本 库 ， 然 后 
再 用 git-svn 将 Subversion 版 本 库 迁 移 到 Git 。 


天 于 cvs2svn 及 cvs28git 的 更 多 信息 ， 可 以 参考 下 面 的 链接 : 
http://cvs2svn.tigris.org/cvs2svn.html 


http://cvs2svn.tigris.org/cvs2git.html 
34.1 安装 cvs2svn ( 含 cvs2git) 
34.1.1 Linux 下 cvs2svn 的 安装 


大 部 分 Linux 发 行 版 都 提供 cvs2svn 的 发 布 包 ， 可 以 直接 用 平台 
自 带 的 cvs2svn 软 件 包 。cvs2svn 从 2.1 版 本 开始 引入 了 到 Git 库 的 转换 ， 


2.3.0 版 本 有 了 独立 的 cvs2git 转 换 脚本 ，cvs2git 正 在 逐渐 完善 当中 ， 
此 请 尽量 选择 最 狐 版 本 的 cvs2svn 。 


例如 在 Debian 或 Ubuntu 下 ， 可 以 通过 下 面 的 命令 查看 源 里 面 的 
cvs2svn 版 本 。 


$aptitude versions cvs2svn 
p 2.1.1-1 stable 990 
p 2.3.0-2 testing,unstable 1001 


可 以 看 出 Debian 的 Testing 和 Sid 仓 库 中 才 有 2.3.0 版 本 的 cvs2svn。 于 
是 执行 下 面 的 命令 安装 在 Testing 版 本 才 有 的 2.3.0-2 版 本 的 cvs2svn: 


$sudo aptitude install cvs2svn/testing 


如 有 果 对 应 的 Linux 发 行 版 没有 对 应 的 版 本 也 可 以 从 源码 开始 安装 。 
cvs2svn 的 官方 版 本 库 在 http:Wcvs2svn.tigris.org/svn/cvs2svn/trunk 上 ， 已 
经 有 人 将 cvs2svn 项 目 转换 为 Git 库 。 可 以 从 Git 库 下 载 源 码 并 安装 
cvs2svn， 具 体操 作 步 又 如 下 : 


(1) 下 载 cvs2svn 源 代码 。 


$git clone git://repo.or.cz/cvs2svn.git 


(2) 进入 cvs2svn 源 码 目录 ， 安 装 cvs2svn 。 


$cd cvs2svn 
$sudo make install 


(3) 过 磋 用 性 手 州 


$sudo make man 


cvs2svn 对 其 他 软件 包 的 依赖 如 下 : 
Python 2.4 或 以 上 版 本 ， 但 是 Python 3.x 暂 不 文 持 。 
RCS: 如 果 在 转换 中 使 用 了 --use-rcs， 就 需要 安装 RCS 软 件 包 [2 。 


CVS: 如 果 在 转换 中 使 用 了 --use-cvs， 就 需要 安装 CVS 软 件 包 。 
[3] 


Git: 1.5.4.4 或 以 上 的 版 本 。 之 前 版 本 的 Git 的 git fast-import 命 令 有 
Bug， 加 载 cvs2git 导 出 文件 有 问题 。 


[1| http://cvs2svn .tigris.org/ 
[2| http://www.cs.purdue.edu/homes/trinkle/RCS/ 


[3] http:/www.nongnu.org/cvs/ 


34.1.2” Mac OS X 下 cvs2svn 的 安装 


Mac OS X 下 可 以 使 用 brew 安 故 cvs2svn， 有 具体 步骤 如 下 : 


(1) Mac OS X 默 认 安 装 的 Python 缺少 cvs2svn 依 赖 的 gdbm 模 组 ， 
完 用 brew 来 重新 安装 Python 。 


$brew install python 
(2) 安装 cvs2svn 。 


$export PATH=/usr/local/bin:$PATH 
$brew install cvs2svn 


34.2 有 版 本 库 转 换 的 准备 工作 


34.2.1 版 本 库 转换 注意 事项 


转换 CVS 版 本 库 时 应 该 注意 以 下 事项 : 


使 用 cvs2git 转 换 CVS 版 本 库 必须 在 CVS 的 服务 器 端 执 行 ， 即 
cvs2git 必 须 能 够 通过 文件 系统 直接 访问 CVS 版 本 库 中 的 "，v" 文 件 。 


在 转换 前 ， 确 保 所 有 人 的 修改 都 已 经 提交 到 CVS 版 本 库 中 。 


在 转换 前 ， 停 止 对 CVS 版 本 库 的 访问 ， 以 免 在 转换 过 程 中 有 新 提 
交 写 入 。 


在 转换 前 ， 对 原始 版 本 库 进 行 备份 ， 以 免 误 操作 对 版 本 库 造 成 永 
久 的 破坏 。 


在 转换 完成 后 ， 永 久 停止 CVS 厂 本 库 的 写 入 服务 ， 可 以 仅 开放 只 


读 服 务 。 


这 是 由 于 cvs2git 是 一 次 性 操作 ， 不 能 对 CVS 的 后 续 提交 执行 增 量 
式 的 到 Git 库 的 转换 ， 因 此 当 CVS 版 本 库 转 换 完 毕 后 ， 须 停 上 CVS 服 


务 。 


先 做 小 规模 的 试验 性 转换 。 

转换 CVS 版 本 库 切 忌 一 上 来 束 对 整个 版 本 库 进行 转换 ， 等 到 发 现 
日 志 乱码 、 文 件 名 乱码 、 提 交 者 ID 不 完全 后 重新 转换 会 浪费 大 量 的 时 
间 。 

应 该 先 选 择 CVS 版 本 库 中 的 部 分 文件 和 目 永 作为 样本 ， 进 行 小 规 
模 的 转换 测试 。 


不 要 对 包含 CVSROOT 目 录 的 版 本 库 的 根 进行 操作 ， 可 以 先 对 服 
务 句 目录 的 布局 进行 调整 。 如 果 转 换 直 接 针 对 包含 CVSROOT 目 隶 的 
版 本 库 根 目录 进行 操作 ， 会 导致 CVSROOT 目 录 下 的 文件 及 更 改 历史 
也 被 纳入 到 Git 版 本 库 中 ， 这 是 不 需要 的 。 


34.2.2 ”文件 名 乱码 问题 


CVS 中 保存 的 数据 在 服务 器 端 直接 和 同名 文件 〈 文 件 多 了 一 个 "， 
Vv" 后 级 ) 相对 应 ， 如 果 转 换 的 CVS 版 本 库 是 从 其 他 平台 (如 
Windows) 上 拷贝 过 来 的 ， 就 可 能 因为 平台 本 身 字 符 集 不 一 致 而 导致 
中 文 文件 名 包含 乱码 ， 从 而 在 CVS 版 本 库 的 转换 过 程 造成 乱码 。 可 以 
先 对 有 问题 的 目录 名 和 文件 名 进行 重 命 名 ， 将 其 转换 为 当前 平台 正确 
的 编码 。 


34.2.3 ”提交 说 明 乱 码 问 题 


CVS 的 提交 说 明 中 如 果 使 用 了 中 文 ， 在 转换 后 的 版 本 库 中 可 能 显 
示 为 乱码 ， 这 是 因为 CVS 的 提交 说 明 没有 使 用 UTF-8 字 符 集 。 前 面 提 
到 过 ， 最 好 先进 行 小 规模 的 试验 性 转换 ， 然 后 再 对 整个 版 本 库 进 行 正 
式 的 转换 ， 殊 是 为 了 防止 在 匆忙 转换 后 发 现 提交 说 明 中 出 现 乱 码 。 


下 面 来 看 一 个 使 用 了 中 文 提交 说 明 的 CVS 版 本 库 。 版 本 库 是 按 如 
下 方式 部 署 的 ，CVSROOT 为 /cvshome/user， 需 要 将 之 下 的 
jiangxin/homepage/worldhello 转 换 为 一 个 Git 版 本 库 。 移 检查 一 下 版 本 
库 中 的 数据 ， 找 出 典型 的 目录 用 于 转换 。 


典型 的 数据 是 这 样 的 ， 包含 中 文 文件 名 ， 并 且 日 志 中 包含 中 文 。 
例如 在 版 本 库 中 ， 执 行 CVS 查 看 日 志 命令 ， 可 以 看 到 类 似 下 面 的 输 
i 


RCS 
file:/cvshome/user/jiangxin/homepage/worldhello/archive/2003/.mhona 
rc.db,V 

wWorking file:archive/2003/ ,mhonarc ,db 

head :1.16 

branch : 

locks:strict 

access list: 

symbolic names : 

keyword substitution:kv 

total revisions:16;selected revisions:16 

description: 


revision 1.16 

date:2004-09-21 15:56:30+0800; author:]jiangxin; state:Exp; 
lines:+3-3; commitid:c2c414fdea20000; 

<D0><<U+07B8><C4><D3>?3<<FE><B5><D8><A3><<BB>> 

<DO> <U+07B8> <c4> <CB> <D1> <CB> <F7> <D2> <FD><Cc7> 共 


此 版 本 库 之 前 用 CVSNT 维 护 ， 黑 认 字 符 集 为 GBK， 所 以 会 在 使 用 
UTF-8 字 人 符 集 的 操作 系统 上 看 到 乱码 。 那 么 这 里 选取 提交 说 明 存 在 乱 
码 的 目录 进行 一 次 试验 性 的 转换 ， 具 体操 作 过 程 如 下 。 


(1) 调用 cvs2git 执 行 转换 ， 产 生 两 个 导出 文件 。 这 两 个 导出 文件 
将 作为 Git 版 本 库 创 建 时 的 导入 文件 。 命 令 行 用 了 两 个 --encoding 参 数 
设置 编码 ， 会 依次 笑 试 将 日 志 中 的 非 ASCII 子 符 转 换 为 UTF-8 子 符 。 


$cvs2git--blobfile git-blob.dat--dumpfile git-dump.dat\ 
--encoding utf8--encoding gbk--username cvs2git\ 
/cvshome/user/jiangxin/homepage/worldhello/archive/2003/ 


(2) 成 功 导 出 后 ， 产 生 两 个 导出 文件 ， 一 个 保存 各 个 文件 的 各 个 
不 同 版 本 的 数据 内 容 ， 即 在 命令 行 指定 的 输出 文件 git-blob.dat。 男 外 
一 个 文件 是 上 面 的 命令 行 指 定 的 git-dump.dat， 用 于 保存 各 个 提交 的 相 
关 信 息 (提交 者 、 提 交 时 间 、 提 交 日 志 等 ) 。 可 以 看 出 保存 文件 内 容 
的 导出 文件 (git-blob.dat) 相对 更 大 一 些 。 


$du-sh git*dat 
9.8M git-blob.dat 
24K git-dump.dat 


(3) 创建 到 的 Git 库 ， 使 用 Git 通 用 的 数据 迁移 命令 git fast-import 
将 cvs2git 的 导出 文件 导入 到 版 本 库 中 。 


$mkdir test 

$cd test 

$git init 

$cat../git-blob.dat../git-dump.dat|git fast-import 


$git reset HEAD 

$git checkout. 

$git lo0g-1 

commit 8334587cb241076bcd2e710b321e8e16b5e46bba 
Author:jiangxin<> 

Date:Tue Sep 21 07:56:31 2004+0000 

修改 邮件 地 址 ; 
修改 搜索 引擎 ，; 


很 好 ， 导 出 的 Git 库 日 志 中 ， 中 文 乱码 问题 已 经 解决 。 但 是 ， 提 区 
日 志 中 的 Author 对 应 的 提交 者 不 完整 :缺乏 邮件 地 址 。 这 是 因为 CVS 
的 提交 者 仅 为 用 户 登 录 ID， 而 Git 的 提交 者 信息 还 要 包含 邮件 地 址 。 
cvs2git 提 供用 户 名 映 映 的 方法 ， 不 过 不 能 使 用 命令 行 调用 cvs2git， 而 
征 有 要 通过 加 载 配置 文件 来 运行 。 因 此 正式 进行 的 CVS 到 Git 厂 本 库 转 换 
要 采用 下 面 介 绍 的 转换 方法 。 


34.3 ”版 本 库 转 换 


使 用 命令 行 参数 调用 cvs2git 厅 烦 、 可 重用 性 差 ， 而 且 可 配置 项 有 
限 。 采 用 cvs2git 配 置 文件 模式 运行 不 但 能 够 简化 cvs2git 的 命令 行 参 
数 ， 而 且 还 能 够 提供 更 多 的 、 命 令 行 无 法 提供 的 配置 项 ， 可 以 更 精确 
地 对 CVS 到 Git 版 本 库 的 转换 进行 定制 。 


34.3.1 配置 文件 解说 


cvs2svn 软 件 包 提供 了 一 个 cvs2git 的 配置 示例 文件 ， 见 源码 中 的 文 


件 cvs2gitrexample.optionsL 。 


将 该 示例 文件 在 本 地 复制 一 份 对 其 进行 更 改 。 该 文件 是 Python 代 
码 格式 ， 以 “#”( 井 号 ) 开始 的 行 是 注释 ， 不 要 随意 更 改 文件 缩 进 ， 
为 缩 进 也 和 是 Python 语 法 的 一 部 分 。 可 以 考虑 针对 下 列 的 选项 进行 定 
制 。 


(1) 设置 CVS 版 本 库 位 置 。 
使 用 配置 文件 方式 运行 cvs2git， 只 能 在 配置 文件 中 设置 要 转换 的 
CVS 版 本 库 位 置 ， 而 不 能 在 命令 行进 行 设 置 。 有 具体 来 说 ， 是 在 配置 文 
件 最 后 面 的 run_options 的 set_project 方 法 中 指定 。 


run_options,set_project( 
#CVS 版 本 库 的 位 置 (不 是 工作 区 , 而 是 包含 ,v 文 件 的 版 本 库 ) 
# 可 以 十 版 本 库 下 的 子 目录 。 


r '/cvshome/user/jiangxin/homepage/worldhello/archive/2003/", 


(2) 设置 导出 文件 的 位 置 。 


将 CVS 版 本 文件 的 内 容 导 出 至 blob 导 出 文件 : cvs2svn-tmp/git- 
blob.dat ° 


还 设置 了 使 用 更 稳定 的 "cvs" 命 令 进行 导出 。 


ctx.revision collector=GitRevisionCollector( 
'cvs2svn-tmp/git-blob.dat', 
#RCSRevisionReader(co_ executable=r 'co'), 
CVSRevisionReader(cvs executable=r 'cvs'), 


) 


另外 一 个 导出 文件 的 位 置 设 定 。 默 认 位 置 : cvs2svn-tmp/git- 


dump.dat。 


ctx.output_option=Gitoutputoption( 
os.path,join(ctx.tmpdir，'git-dump,dat')， 

#The blobs will] be written via the revision recorder,so in 
#0utputPass we only have to emit references to the blob marks: 
GitRevisionMarkwriter(), 

#0ptional map from CVS author names to git author names: 
author_transforms=author_transforms, 


) 


(2) 设置 无 提交 用 户 信息 时 使 用 的 用 户 名 。 这 个 用 户 名 可 以 用 接 
下 来 的 用 户 映射 较 换 为 Git 用 户 名 。 


ctx,.Username='cvSs2SVvn' 


(3) 建立 CVS 用 户 和 Git 用 户 之 间 的 映射 。Git 用 户 名 可 以 用 
Python 的 元 组 (tuple) 语法 (name,email) 或 字符 串 umame< email >， 
器 来 表示 。 


author_transforms={ 
'jiangxin':('Jiang Xin','jiangxin@ossxp.com'), 


'devi1' 
:U' 开 发 者 1< dev1@ossxp.com> '， 
"CVS2Svn' : "cvS2Svn<adminQ@examp1le.com> "， 


(4) 字符 集 编码 。 即 如 何 转换 日 志 中 的 用 户 名 、 提 交 说 明 及 文件 
名 的 编码 。 


对 于 可 能 在 日 志 中 出 现 的 中 文 ， 必 须 做 出 与 下 面 类 似 的 设置 。 编 
码 的 顺序 对 输出 会 有 影响 ， 一 般 将 utf8' 放 在 'gbk 之 前 ， 以 保证 当日 志 
中 同时 出 现 两 种 编码 时 都 能 正常 转换 。 (这 是 因为 部 分 中 文 的 UTF8 编 
码 在 GBK 中 也 存在 着 古怪 的 对 应 。) 


ctx.cvs_author_decoder=CVSTextDecoder( 


[ 
'utf8"', 
'gbk', 


]， 
fallback_encoding="'gbk' 
) 


ctx.cvs_log_decoder=CVSTextDecoder( 
'utf8"', 

'gbk', 

]， 


fallback_encoding="'gbk' 


) 


ctx.cvs_filename_decoder=CVSTextDecoder( 


'utf8"', 
'gbk', 


#fallback_encoding="'ascii' 


) 


(5) 是 


否 忽略 .cvsignore 文 件 ? 默认 保留 


无 论 选择 保留 或 是 不 保留 ， 最 好 在 转换 后 
到 .gitignore 的 转换 。 因 为 cvs2git 不 能 人 
为 .gitignore 文 件 。 


ctx.keep_cvsignore=True 


持 点 


(6) 对 文件 换行 符 等 的 处 理 。 
Subversion 的 属性 转换 ， 但 


认 值 比较 安全 


.cvsignore 文件 。 


进行 .cvsignore 


ctx.file property_setters.extend([ 


# 直 


# 对 于 二 进 制 文 伯 


于 配置 文 
#MimeMapper(r '/e 


件 设置 文件 的 mime 类 型 
tc/mime.types',ignore case=False), 
属性 (对 于 Subversion 来 说 ) 


F( - kb 模式 ) 不 设置 svn:eo1-style 


CVSBinaryFileEOLStylesSetter(), 


# 


# 


如 采 文 件 是 二 进 制 ， 


‘application/octet-stream'° 
CVSBinaryFileDefaultMimeTypeSetter(), 


如 果 希 望 术 


据 文件 的 mime 类 型 来 判断 文件 的 换行 符 ， 


#EOLStyleFromMimeTypeSetter(), 


共 
共 
共 


如 果 上 面 的 规则 没有 为 文 但 
(二 进 制 文件 除外 ) 


默认 把 文人 


F 视 为 二 进 


,不 为 


是 也 会 影响 到 Git 转 换 时 的 换行 符 


并 且 还 没有 设置 svn :mime-type, 将 其 设置 为 


打开 下 面 的 注释 


下 面 的 配置 原本 是 针对 CVS 到 | 


设置 。 维 


F 设 置换 行 符 类 型 , 则 为 svn : eol-style 设 置 


最 安全 


其 设置 换行 符 类 型 ,这 样 


承认 类 型 


# 如 采 了 确认 CVS 的 二 进 制 文件 都 已 经 设置 了 -kb 参数 ,或 者 使 用 规则 能 够 对 
文件 类 型 做 出 正确 判断 ,也 可 以 使 用 下 面 的 参数 为 非 二 进 制 文件 设置 默认 换行 符号 
## 'native' :服务 器 端 文件 的 换行 符 保 存 为 LF, 客户 端 根据 需要 自动 转换 

## 'CRLF' :服务 器 端 文件 的 换行 符 保 存 为 CRLF, 客户 端 亦 为 CRLF 

## 'CR' :服务 器 端 文件 的 换行 符 保 存 为 CR, 客户 端 亦 为 CR 

## 'LF' :服务 器 端 文件 的 换行 符 保存 为 LF, 客户 端 亦 为 LF 
DefaultEOLStyleSetter(None), 

# 如 果 文 件 没 有 设置 svn :eo0l1-style, 也 不 为 其 设置 svn :keywords 属 性 
SVNBinaryFileKeywordsPropertySetter(), 

# 如 果 没 有 设置 svn :keywords, 基于 文件 的 CVS 模 式 进 行 设置 。 
KeywordsPropertySetter(config.SVN_KEYWORDS_VALUE), 

# 设 置 文件 的 svn :executable 属 性 , 如 果 文 件 在 CVS 中 标记 为 可 执行 文件 
ExecutablePropertySetter(), 

]) 


下 
I 

| 

I 


-可 


a 
Eph 
| 


O 


(7) 是 否 只 迁移 主线 ， 忽 略 分 文 和 里 程 牧 ? 


默认 对 所 有 分 文 和 里 程 碑 都 进行 转换 。 如 果 选 择 忽 略 分 文 和 里 程 
人 碑 ， 则 将 False 修 改 为 True 。 


ctx.trunk_only=False 


(8) 分 文 和 里 程 碑 的 迁移 及 转换 。 


global_symbol_strategy_rules=[ 

# 和 正则 表达 式 匹配 的 CVS 标 识 , 转换 为 6it 的 分 支 
#ForceBranchRegexpStrategyRule(r "branch.* ')， 
# 和 正则 表达 式 匹 配 的 CVS 标 识 , 转换 为 6it 的 里 程 碑 
#ForceTagRegexpStrategyRule(r 'tag.*'), 

# 忽 略 和 正则 表达 式 匹 配 的 CVS 标 识 , 不 进行 (到 6it 分 支 / 里 程 碑 ) 转 换 
#ExcludeRegexpStrategyRule(r 'unknown-.*"), 

# 有 歧义 的 CVS 标 识 的 处 理 选项 

# 默 认 根 据 使 用 频率 自动 确定 转换 为 分 支 或 里 程 碑 
HeuristicSstrategyRule(), 

# 或 者 全 部 转换 为 分 支 
#AllBranchRule( ), 
# 或 者 全 部 转换 为 里 程 碑 
#AllTagRule( ), 


run_options,set_project( 


#A list of Symbol transformations that can be used to rename 


Symbols in this project. 
symbol_transforms=[ 
# 是 否 需 要 重新 命名 里 程 碑 ? 第 一 个 参数 用 于 匹配 ,第 二 个 参数 用 于 替换 。 
#RegexpSymbolTransform(r 'release-(\d+)_(\d+)',r ' release- 


\1.\2'), 
#RegexpSymbolTransform(r 'release-(\d+)_(\d+)_(\d+)',r 'release- 


NT WNT) 


[1| http://repo.or.cz/w/cvs2svn.git/blob/HEAD:/cvs2git-example.options 
[2] 字符 串 前 面 的 字符 u 声 明 该 字符 串 以 Unicode 格 式 保存 。 


34.3.2 ”运行 cvs2git 完 成 转换 


参照 上 面 的 方法 ， 从 默认 的 cvs2git 配 置 文件 来 进行 定制 ， 在 本 地 
创建 一 个 文件 (例如 名 为 cvs2git.options 的 文件 ) 。 然 后 运行 cvs2git 完 
成 版 本 库 转 换 ， 有 具体 操作 步骤 如 下 。 


(1) 使 用 cvs2git 配 置 文件 ， 命 令 行 大 大 简化 了 。 


$cvs2git--options cvs2git.options 


(2) 成 功 导出 后 ， 产 生 两 个 导出 文件 ， 痢 保存 在 cvs2git-tmp 目 录 


一 个 保存 各 个 文件 的 各 个 不 同 版 本 的 数据 内 容 ， 即 命令 行 指定 的 
输出 文件 git-blob.dat。 男 外 一 个 文件 是 上 面 命令 行 指 定 的 git- 
dump.dat， 用 于 保存 各 个 提交 的 相关 信息 (提交 者 、 提 交 时 间 、 提 交 


日 志 等 ) 。 


可 以 看 出 保存 文件 内 容 的 导出 文件 相对 更 大 一 些 。 


$du-sh cvs2svn-tmp/* 
9.8M cvs2svn-tmp/git-blob.dat 
24K cvs2svn-tmp/git-dump.dat 


(3) 创建 到 的 Git 库 ， 使 用 Git 通 用 的 数据 迁移 命令 git-fast-import 
将 cvs2git 的 导出 文件 导入 到 版 本 库 中 。 


$mkdir test 

$cd test 

$git init 

$cat../cvs2svn-tmp/git-blob.dat\ 
,./CcVS2svn-tmp/git-dump.dat|git fast-import 


(4) 检查 导出 结果 。 


$git reset HEAD 

$git checkout. 

$git lo0g-1 

commit e3f12f57a77cbffcf62e19012507d041f1c9b03d 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Sep 21 07:56:31 2004+0000 

修改 邮件 地 址 ; 
修改 搜索 引擎 ，; 


可 以 看 到 ， 这 一 次 的 转换 结果 不 但 使 得 日 志 中 的 中 文 可 以 显示 ， 
而 且 提 交 者 ID 也 转换 成 了 Git 的 风格 。 


34.4 迁移 后 的 版 本 库 检 查 


还 需要 进行 细致 的 检查 。 


sll 
人 
下 
SS 
内 | 
-| 
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1, 文 件 名 和 目 赤 中 的 中 你 


如 果 转 换 过 程 参考 了 前 面 的 步 又 和 注意 事项 ， 文 件 名 和 版 本 库 提 
区 日 志 中 的 中 文 束 不 应 该 出 现 乱 码 。 


2. 图 片 文件 被 破坏 


最 典型 的 错误 束 是 转换 后 部 分 图 片 被 破坏 从 而 无 法 显示 。 这 是 怎 
么 造成 的 呢 ? 


CVS 默 认 将 提交 的 文件 以 文本 方式 添加 ， 除 非 用 户 在 添加 文件 时 
使 用 了 -kb 参数 。 用 命令 行 提交 的 用 户 经 常会 写 记 使 用 -kb 参数 ， 这 就 
导致 一 些 二 进 制 文件 (如 图 片 文件 ) 以 文本 文件 的 方式 被 添加 到 其 
中 。 文 本 文件 在 CVS 检 入 和 检 出 时 会 进行 换行 符 转 换 ， 在 服务 器 端 换 
行 符 保存 为 LF， 在 Windows 上 检 出 时 为 CRLF。 如 果 误 以 文本 文件 方式 
添加 的 图 片 中 恰好 出 现 了 CRLF， 则 在 Windows 上 似乎 没有 问题 (仍然 
是 CRLF) ,但 是 CVS 库 转换 成 Git 库 后 ， 图 片 文件 在 Windows 上 再 检 出 
时 ， 文 件数 据 中 原来 的 CRLF 就 被 换 成 了 LF， 导 致 文件 被 破坏 。 


出 现 这 种 情况 是 CVS 版 本 库 的 使 用 和 管理 上 出 现 了 问题 ， 应 该 在 
CVS 版 本 库 中 对 有 问题 的 文件 重新 设置 属性 ， 标 记 为 二 进 制 文件 。 然 
后 再 进行 CVS 版 本 库 到 Git 库 的 转换 。 


3..cvsignore 文 件 的 转换 


CVS 版 本 库 中 可 能 存在 .cvsignore 文 件 用 于 设置 文件 忽略 ， 相 当 于 
Git 版 本 库 中 的 .gitignore。 因 为 当前 版 本 的 cvs2git 不 能 目 动 将 .cvsignore 
转换 为 .gitignore， 这 就 需要 在 版 本 库 迁 移 后 手工 完成 。CVS 
的 .cvsignore 文 件 只 对 目录 内 的 文件 有 效 ， 不 会 同 下 作用 到 子 目 录 上 ， 
这 一 点 和 Git 的 .gitignore 不 同 。 还 有 .cvsignore 文 件 每 一 行 都 用 空格 分 割 
多 个 忽略 ， 而 Git 的 每 个 忽略 单独 为 一 行 。 


4. 迁 移 后 的 测试 


一 个 位 单 的 检查 方法 是 ， 在 同一 台 机 右上 分 别 用 CVS 和 Git 检 出 
(或 元 隆 ) ， 然 后 比较 本 地 的 差异 。 要 在 不 同 的 系统 上 (Windows、 


Linux) 分 别 进行 测试 。 


第 35 章 ”更 多 版 本 欣 制 系统 的 迁移 


35.1 SVN 版 本 库 到 Git 的 迁移 


Subversion 版 本 库 到 Git 版 本 库 的 转换 ， 最 好 的 方法 就 是 git-svn。 
而 git-svn 的 使 用 方法 在 前 面 “第 26 章 ”Git 和 SVN 协 同 模型 ”一 章 中 己 经 
详细 介绍 过 。 本 章 的 内 容 将 不 再 对 git-svn 的 用 法 做 过 多 的 重复 ， 只 在 
这 里 强调 一 下 版 本 库 迁 移 时 的 注意 事项 ， 相 关 git-svn 的 内 容 还 请 参照 
第 4 篇 “第 26 章 ”Git 和 和 SVN 协同 模型 ”。 


在 迁移 之 前 要 确认 一 个 问题 ，Subversion 转 换 到 Git 库 之 后 ， 


Subversion 还 能 继续 使 用 吗 ? 意思 是 说 还 允许 同 Subversion 提 交 吗 ? 


如 果 回 答 是 ， 那 么 直接 查看 “第 26 章 Git 和 SVN 协 同 模型 >”， 用 Git 作 
为 前 端 工具 来 操作 Subversion 版 本 库 ， 而 不 要 理会 下 面 的 内 容 。 因 为 下 
面 描述 的 迁移 步骤 针对 的 是 Subversion 到 Git 版 本 库 的 一 次 性 的 迁移 。 


1. 不 在 提交 说 明 中 出 现 git-svn-id 标 识 


如 果 一 次 性 、 永 久 性 地 将 Subverison 迁 移 到 Git 库 ， 可 以 选择 "git- 
svn-id:" 标 识 不 在 转换 后 的 Git 的 提交 日 志 中 出 现 ， 这 样 根 本 看 不 出 来 转 
换 后 的 Git 库 曾经 用 Subversion 版 本 库 维 护 过 。 


在 git-svn 的 clone 或 init 子 命令 行 中 使 用 参数 : --no-metadata。Git 库 
的 配置 会 自动 将 svn-remote.noMetadata 配 置 为 1。 之 后 执行 git svn fetch 
时 吏 不 会 在 日 志 中 产生 "git-svn-id:" 标 识 。 


2.Subversion 用 户 名 到 Git 用 户 名 的 映射 


默认 转换 后 Git 库 的 提交 者 ID 为 如 下 格式 : userid< userid@SVN- 
REPOS-UUID > ， 即 在 邮件 地 址 的 域名 处 以 SVN 版 本 库 的 UUID 代 替 。 
可 以 在 执行 git svn fetch 时 ， 通 过 下 面 的 参数 提供 一 个 映射 文件 完成 
SVN 用 户 名 到 Git 用 户 名 的 转换 。 


-A<filename>,--authors-file=<filename> 


即 用 -A 或 --authors-file 参 数 给 出 一 个 映射 文件 ， 这 个 文件 帮助 git- 
svn 将 Subversion 用 尸 名 映射 为 Git 用 户 名 。 此 文件 的 每 一 行 定义 一 个 用 
户 名 映 冉 ， 每 一 行 的 格式 为 : 


loginname=User Name <user@example.com> 


也 可 以 通过 下 面 的 命令 在 Git 库 的 config 文 件 中 设置 ， 这 样 吏 不 必 
在 每 次 执行 git svn fetch 时 都 带 上 这 个 参数 。 


$git config svn.authorsfile/path/to/authersfile 


当 设 是 了 用 户 映 射 文件 后 ， 如 果 在 执行 git svn fetch 时 发 现 SVN 的 
用 户 在 该 映射 文件 中 没有 定义 ， 转 换 过 程 被 中 断 。 需 要 重新 编辑 用 户 
映射 文件 ， 补 充 新 的 用 户 映 射 后 ， 再 重新 执行 git-svn 命 令 。 


3. 里 程 碑 和 分 文 的 转换 


使 用 默认 的 参数 执行 SVN 到 Git 的 转换 时 ，SVN 的 里 程 碑 和 分 文 转 
换 到 Git 库 的 refsxremotes 引 用 下 。 这 会 导致 其 他 人 从 转换 后 的 Git 库 克隆 
时 ， 看 不 到 Subversion 原 有 的 分 文 和 里 程 碑 。 


当 以 默认 的 参数 执行 git svn init 时 ，Git 的 配置 文件 中 会 生成 下 面 
的 配置 : 


[svn-remote "svn"] 
fetch=trunk:refs/remotes/trunk 
branches=branches/*:refs/remotes/* 
tags=tags/*:refs/remotes/tags/* 


可 以 直接 编辑 Git 配 置 文件 ， 将 其 内 容 调 整 如 下 : 


[svn-remote "svn"] 
fetch=trunk:refs/heads/master 
branches=branches/*:refs/heads/* 
tags=tags/*:refs/tags/* 


之 后 ， 再 执行 git svn fetch 后 ， 就 可 以 实现 SVN 的 分 支 和 里 程 碑 正 
确 地 转换 为 Git 库 的 里 程 碑 。 否 则 如 有 果 不 对 Git 配 置 文件 作出 调整 ， 束 


需要 手动 将 .git/refs/remots/ 下 的 引用 移动 到 .git/refs/heads 及 .git/refs/tags 
es 


4. 清 除 git-svn 的 中 间 文 件 


git-svn 的 中 间 文 件 位 于 目录 .git/svn 下， 删除 此 目录 完成 对 git-svn 转 
换 数 据 库 文 件 的 清理 。 


35.2 Hg 版 本 库 到 Git 的 迁移 


Mercurial (水 银 ) 是 和 Git 同 时 代 的 、 与 之 齐名 的 一 款 著 名 的 分 布 
式 版 本 控制 系统 ， 也 有 相当 多 的 使 用 者 。 束 像 水 银 又 名 来 一样， 作为 
版 本 控制 系统 的 Mercurial 又 称 作 Hg (水 银元 杂 符 号 ; 。Hg 具 有 人 向 单 易 
用 的 优点 ， 至 少 Hg 按 提交 的 顺序 递增 的 数 子 编号 让 Subversion 用 户 感 
到 更 为 亲切 。Hg 的 开发 语言 除 少 部 分 因 性 能 原因 使 用 C 语 言 外 ， 大 部 
分 用 Python 语言 开发 完成 ， 因 而 更 易 扩 展 ， 最 终 形 成 了 Hg 最 具 特 色 的 
插件 系统 。 例 如 MQ 了 束 是 Hg 一 个 很 有 用 的 插件 ， 通 过 Quilt 式 的 补丁 集 
实现 对 定制 开发 的 特性 分 文 的 版 本 欣 制 ， 当 然 StGit 和 Topgit 也 可 以 实 
现 类 似 的 功能 。 


但 是 Hg 存在 一 些 不 足 。 例 如 服务 器 的 存储 效率 不 能 和 Git 相 比 ， 服 
务 器 存储 空间 占用 更 大 。Hg 还 不 支持 真正 的 分 文 ， 所 以 不 能 向 gitrsvn 
那样 完整 地 对 Subversion 版 本 库 进 行 转换 和 互 操 作 。Hg 的 提交 只 能 
退 一 次 ， 要 想 多 次 回 退 和 整理 版 本 库 需 要 用 到 MQ 插 件 。 作 为 定制 开 
发 的 利器 ，Hg+MQ 不 适合 多 人 协作 开发 而 Gitt+Topgit 更 为 适合 。 


不 论 是 何 原因 如 果 想 从 Hg 迁移 到 Git， 用 一 个 名 为 fast-export 的 转 
换 工 具 束 可 以 很 方便 地 实现 。fast-export 十 一 个 用 Python 开 发 的 命令 行 
工具 ， 可 以 将 本 地 的 Hg 版 本 库 迁 移 为 Git 版 本 库 。 其 原理 和 CVS 版 本 库 


迁移 至 Git 时 使 用 的 cvs2git 相 仿 ， 都 是 先 从 源 有 版 本 库 生 成 导出 文件 ， 再 
用 Git 的 通用 版 本 库 转 换 工 具 git-fast-import 导 入 到 新 建 的 Git 版 本 库 中 。 


安装 fast-export 非 常 简单， 只 要 用 Git 克 隆 fast-export 的 版 本 库 即 
本 


$cd/path/to 
$git clone git://repo.or.cz/fast-export.git 
完成 元 隆 后 ， 会 看 到 /path/to/fast-export 目 录 中 有 一 个 名 为 hg-fast- 
import.sh 的 脚本 文件 ， 该 文件 封装 了 对 相应 Python 脚本 的 调用 。 使 用 
该 脚本 可 以 实现 Hg 版 本 库 到 Git 版 本 库 的 迁移 。 


下 面 就 演示 一 下 Hg 版 本 库 到 Git 版 本 库 的 转换 ， 具 体操 作 过 程 如 
下 。 (1) 要 转换 的 Hg 版 本 库 位 于 路 径 /path/to/hg/hello/.hg 下 。 


Hg 不 文 持 真正 的 分 文 ， 而 且 版 本 库 中 可 能 存在 尚未 合并 的 多 个 头 
生计 。 检查 一 下 不 要 存在 具有 相同 分 文 名 但 尚未 合并 的 多 个 头 指针 ， 
否则 转换 会 失败 。 下 面 显示 的 该 Hg 版 本 库 中 具有 两 个 具名 分 文 r1.x 和 
next， 还 有 一 个 默认 的 未 设置 名 称 的 头 指针 ， 因 为 分 文 名 各 不 相同 所 

以 不 会 为 转换 过 程 造成 脐 烦 。 


$hg heads 

修改 集 :7:afdd475caeee 
分 支 :rd1,X 

标签 :tip 


本 


父亲 :0:798a9568e10e 


j 户 :Jiang Xin<jiangxin@ossxp.com> 

日 期 :Fri Jan 14 17:01:47 2011+0800 

搬 述 : 

start new branch:r1.x 

修改 集 :6:7f5a46201dda 

分 支 :next 

j 户 :Jiang Xin<jiangxin@ossxp.com> 

日 期 :Fri Jan 14 17:01:04 2011+0800 

文件 :src/locale/zh_CN/LC_MESSAGES/helloworld.po 
搬 述 : 
imported patch 100_locale zh_cn.patch 

修改 集 :1:97f0a21021c6 

jj 户 :Jiang Xin<worldhello.net AT gmail DOT com> 
日 期 :Sun Aug 23 23:53:05 2009+0800 

文件 :src/COPYRIGHT src/main.bak src/main.c 

搬 述 : 
Fixed#6:import new upstream version hello-2.0.0 


(2) 初始 化 一 个 Git 版 本 库 ， 该 版 本 库 就 是 迁移 的 目标 版 本 库 。 


$mkdir-p/path/to/my/workspace/hello 

$cd/path/to/my/workspace/hello 

$git init 

Initialized empty Git repository 
in/path/to/my/workspace/hello/ .git/ 


(3) 在 刚刚 完成 初始 化 的 Git 工 作 区 中 调用 hg-fast-export.sh 脚 本 
完成 版 本 库 转 换 。 


$/path/to/fast-export/hg-fast-export.sh-r/path/to/hg/hello 


(4) 转换 完毕 ， 执 行 git branch 会 看 到 Hg 版 本 库 中 的 具名 分 文 都 
被 转换 为 相应 的 分 文 ， 没 有 命名 的 默认 头 指针 被 转换 为 master 分 文 。 


$git branch 
*master 


next 
ri.x 


在 转换 后 的 Git 版 本 库 目 录 中 ， 保 存 了 儿 个 用 于 记录 版 本 库 转换 进 
度 的 状态 文件 (.git/hg2git-*) ， 当 在 Git 工 作 区 不 带 任何 参数 执行 hg- 
fast-export.sh 命 令 时 ， 会 继续 进行 增 量 式 的 转换 ， 将 Hg 版 本 库 中 的 新 
提交 迁移 到 Git 版 本 库 中 。 


如 宁 使 用 了 多 个 不 同 的 Hg 克隆 版 本 库 进 行 分 文 管理 ， 束 需要 对 Hg 
版 本 库 逐 一 进行 转换 ， 然 后 再 对 转换 后 的 Git 版 本 库 进 行 合 并 。 在 合并 
Git 版 本 库 的 时 候 可 以 参考 下 面 的 命令 。 


$git 
$git 
$git 
$git 
$git 


remote add<name1i><path/to/repos/1> 

remote add<name2><path/to/repos/2> 

remote update 
checkout-b<branch1>origin/<name1l>/master 
checkout-b<branch2>origin/<name2>/master 


35.3 ”通用 版 本 库 迁 移 


如 果 在 前 面 的 迁移 方案 中 没有 涉及 您 的 版 本 控制 工具 ， 也 不 要 
紧 ， 因 为 很 可 能 通过 搜索 引擎 束 能 找到 一 款 合适 的 迁移 工具 。 如 有 果 找 
不 到 相应 的 工具 ， 可 能 是 你 使 用 的 版 本 控制 工具 太 冷 | 门 ， 或 者 古 一 款 
不 提供 迁移 接口 的 商业 版 本 控制 工具 趾 。 这 时 你 可 以 通过 手工 检 入 的 
方式 ， 或 者 针对 Git 提 供 的 版 本 库 导 入 接口 git-fast-import 实 现 版 本 库 导 
入 。 


手工 和 检 入 的 方式 适合 于 只 有 少数 几 个 提交 ， 或 者 对 大 部 分 提交 历 
史 不 关心 而 只 需要 对 少数 里 程 碑 版 本 执行 导入 的 版 本 库 导 入 。 这 种 版 
本 库 迁 移 方式 非常 答 单 ， 相 当 于 在 完成 Git 版 本 库 初 始 化 后 ， 在 工作 区 
重复 执行 : 工作 区 文件 清理 (rm-rf) ， 文 件 复制 ， 执 行 git add-A 添 加 
到 和 暂 存 区 ， 执 行 git commit 提 交 。 


但 是 如 采 需 要 将 版 本 库 完 整 的 历史 全 部 迁移 到 痢 的 Git 版 本 库 中 ， 
手工 检 入 的 方法 就 不 可 取 了 ， 针 对 git-fast-import 的 编程 将 是 一 个 好 的 
方法 。Git 所 供 了 一 个 通用 的 版 本 库 导 入 解决 方案 ， 即 通过 辐 命 令 8git 
fast-import 传 递 特定 格式 的 字 市 流 ， 就 可 以 实现 Git 版 本 库 的 创建 。 工 
具 git-fast-import 的 导入 文件 格式 设计 得 相对 比较 简单 ， 当 理解 了 其 格 
式 约定 后 ， 可 以 相对 容易 地 开发 出 针对 特定 版 本 库 的 迁移 工具 。 


1 .数据 混杂 在 提交 中 的 导入 文件 


下 面 就 是 一 个 简单 的 导入 文件 ， 为 说 明 方便 在 前 面 标注 了 行 号 ， 
将 这 个 文件 保存 为 /path/to/file/dump1.dat 。 


commit refs/heads/master 
mark:1 

committer Useri<user1iQ@ossxp.com>1295312699+0800 
data< <EOF 

My in it ialcommit. 

EOF 

M 644 inline README 

data< <EOF 

Hello,world. 

EOF 

11 M 644 inline team/user1.txt 
12 data< <EOF 

13 I'm useri1. 

14 EOF 


BS OO 


上 面 这 段 文字 应 该 这 样 理解 : 


第 1 行 以 commit 开 头 ， 标 记 一 个 提交 的 开始 。 该 提交 会 创建 〈 或 
更 新 ) 引用 refs/heads/master 。 

第 2 行 以 mark 开 头 ， 是 一 个 标记 指令 ， 将 这 个 提交 用 “:12 标 示 以 方 
便 后 面 的 提交 参照 。 


第 3 行 记 录 了 这 个 提交 的 提交 者 是 User1， 邮 件 地 址 为 < 
user1@ossxp.com > ， 提 区 时 间 则 采用 Unix 时 间 格 式 。 


第 4 一 6 行 是 该 提交 的 提交 说 明 ， 提 交 说 明 用 data 数 据 块 的 方式 进 


行 定义 。 


第 4 行 在 data 语 句 后 紧 接 着 的 < <EOF 含 义 为 data 的 内 容 到 以 EOF 
标记 的 行 截止 。 这 样 的 表示 法 称 为 "Here document" 表 示 法 局 。 


第 7 行 以 字母 M 开 头 ， 含 义 是 修改 (或 新 建 了 一 个 文件 ， 文 件 名 
为 README， 而 文件 的 内 容 以 inline 的 方式 提供 。 


第 8 一 10 行 则 是 以 内 联 (inline) 数据 块 的 方式 提供 README 文 件 
的 内 容 。 


第 11 行 定义 了 该 提交 修改 的 第 二 个 文件 team/userl.txt。 该 文件 的 
内 容 也 是 以 内 联 (inline) 的 方式 给 出 。 


第 12~14 行 给 出 文件 teamy/userl.txt 的 内 容 。 


下 面 初 始 化 一 个 新 的 版 本 库 ， 并 通过 导入 文 
件 /pathyto/file/dump1l.dat 的 方式 为 版 本 库 注 入 数据 ， 操 作 步 又 如 下 。 


(1) 初始 化 版 本 库 。 


$mkdir-p/path/to/my/workspace/import 
$cd/path/to/my/workspace/import 
$git init 


(2) 调用 git fast-import 命 令 。 


$git fast-import</path/to/file/dump1.dat 
git-fast-import statistics: 


Alloc'd objects:5000 

Total objects:5(0 duplicates) 
blobs:2(0© duplicates 0 deltas) 
trees:2(0 duplicates 0 deltas) 
commits:1(9 duplicates 0 deltas) 
tags:0(0 duplicates 0 deltas) 
Total branches:1(1 loads) 
marks:1024(1 unique) 

atoms:3 

Memory total:2344 KiB 
pools:2110 KiB 

objects:234 KiB 


pack_report:getpagesize( )=4096 
pack_report:core.packedGitWindowSize=1073741824 
pack_report:core.packedGitLimit=8589934592 
pack_report:pack_used_ctr=1 
pack_report:pack_mmap_calls=1 
pack_report:pack_open_ windows=1/1 
pack_report:pack_mapped=323/323 


(3) 看 看 提交 日 志 。 


$git log--pretty=fuller--stat 

commit 18f4310580ca915d7384b116fcb2e2ca0b833714 
Author:User1<useri@ossxp.com> 

AuthorDate:Tue Jan 18 09:04:59 2011+0800 
Commit:User1i<useri@ossxp.com> 

CommitDate:Tue Jan 18 09:04:59 2011+0800 

My initial commit. 

README | 1+ 

team/user1.txt|1+ 

2 files changed,2 insertions(+),0 deletions(-) 


2. 在 blob 中 定义 数据 并 在 提交 中 引用 的 导入 文件 


再 来 看 一 个 导入 文件 。 将 下 面 的 内 容 保存 到 文 
件 /path/to/file/dump2.dat 中 。 


1 blob 
2 mark:2 3 data 25 

4 Hello,world. 

5 Hi,user2. 

6 blob 

7 mark:3 

8 data< <EOF 

9 I'm user2. 

10 EOF 

11 commit refs/heads/master 

12 mark:4 

13 committer User2<user2@ossxp.com>1295312799+0800 
14 data< <EOF 

15 User2's test commit. 

16 EOF 

17 from:1 

18 M 644:2 README 

19 M 644:3 team/user2.txt 


上 上 面 的 内 容 为 了 说 明 方便 标注 了 行 号， 注意 不 要 把 行 号 也 代入 文 
件 中 入 其 中 : 


第 1 一 5 行 定 义 了 编号 为 “:2” 的 文件 内 容 。 该 文件 的 内 容 共 有 25 个 
字 玫 ， 第 3 行 开始 的 data 文 字 块 通过 在 后 面 跟 上 一 个 表示 文件 长 度 的 十 
进 制 数字 界定 了 内 容 的 起 止 。 


第 6 一 10 行 定义 了 编号 为 “:3” 的 文件 内 容 。 第 8 行 界定 该 文件 内 容 
使 用 了 "here document" 的 语法 ， 使 用 "here document" 语 法 比较 适合 于 文 
本 内 容 ， 使 用 内 容 长 度 标示 内 容 起 止 更 适合 于 二 进 制 文件 。 


第 11 行 开始 定义 了 一 个 新 的 提交 。 


第 12 行 设 定 该 提交 的 编号 为 “:4”。 


第 17 行 以 from 开 头 ， 定 义 了 编号 为 “:1” 的 提交 是 该 提交 的 父 提 
交 ， 即 在 /path/to/file/dump1.dat 中 定义 的 提交 。 


第 18 行 和 第 19 行 设 定 了 该 提交 更 改 的 两 个 文件 ， 这 两 个 文件 的 内 
容 不 像 之 前 的 导出 文件 "dump1.dat" 那 样 使 用 内 联 方 式 定 义 内 容 ， 而 是 
采用 引用 方式 引用 前 面 定 义 的 blob 文 字 块 作为 文件 的 内 容 。 


如 果 以 增 量 方式 导入 dump2.dat 会 报错 ， 因 为 在 第 17 行 引用 
的 <:1* 没 有 定义 。 
$git fast-import</path/to/file/dump2.dat 


fatal:mark:1 not declared 
fast-import:dumping crash report to.git/fast_import_crash_21772 


如 果 将 文件 /path/to/fle/dump2.dat 的 第 17 行 的 引用 修改 为 提交 ID， 
就 可 以 增 量 导 入 了 。 不 过 ， 为 了 说 明 的 方便 ， 还 是 通过 将 两 个 导入 文 
件 一 次 性 传递 给 git fast-import 来 创建 一 个 新 版 本 库 ， 操 作 步 骤 如 下 。 


(1) 初始 化 版 本 库 import2。 


$mkdir-p/path/to/my/workspace/import2 
$cd/path/to/my/workspace/import2 
$git init 


(2) 调用 git fast-import 命 令 。 


$cat/path/to/file/dump1.dat\ 
/path/to/file/dump2.dat|git fast-import 


(3) 导入 之 后 的 日 志 显 示 : 


$git lo0g--graph--stat 

*commit 73a6f2742f9da7c1ib4bb8748e018a2becad39dd6 
[Author:User2<user2Q@ossxp.com> 

|Date:Tue Jan 18 09:06:39 2011+0800 

| 


[User2's test commit. 

| 

|README | 1+ 

|team/user2. txt|1+ 

|2 files changed,2 insertions(+),0©0 deletions(-) 
| 

*commit 18f4310580ca915d7384b116fcb2e2ca0b833714 
Author:User1<useri@ossxp.com> 

Date:Tue Jan 18 09:04:59 2011+0800 

My initial commit. 

README | 1+ 

team/user1.txt|1+ 

2 files changed,2 insertions(+),0 deletions(-) 


3. 包 含 了 合并 提交 及 里 程 碑 的 导入 文件 


下 面 再 来 看 一 个 导入 文件 ， 在 这 个 导入 文件 中 ， 包 含 了 合并 提 
交 ， 以 及 创建 里 程 碑 。 


blob 

mark:5 

data 25 
Hello,world. 
Hi,user1. 
blob 


OODP 


7 mark:6 

8 data 35 

9 Hello,world. 

10 Hi,user1 and user2. 

11 commit refs/heads/master 

12 mark:7 

13 committer User1i<user1i@ossxp.com>1295312899+0800 
14 data< <EOF 

15 Say helo to useril. 

16 EOF 

17 from:1 

18 M 644:5 README 

19 commit refs/heads/master 

20 mark:8 

21 committer User2<user2@ossxp.com>1295312900+0800 
22 data< <EOF 

23 Say helo to both users. 

24 EOF 

25 from:4 

26 merge:7 

27 M 644:6 README 

28 tag refs/tags/v1i.0 

29 from:8 

30 tagger Jiang Xin<jiangxin@ossxp.com>1295312901+0800 
31 data< <EOF 

32 Version v1.0 

33 EOF 


将 这 个 文件 保存 到 /path/to/file/dump3.dat 中 。 下 面 就 针对 该 文件 内 
容 进 行 简要 的 说 明 : 


第 1~5 行 和 第 6~10 行 定义 了 两 个 blob 对 象 ， 代 表 了 对 README 文 
件 的 两 个 不 同 的 修改 。 

第 11 行 开始 定义 了 编号 为 “:7” 的 提交 。 从 第 17 行 可 以 看 出 该 提交 
的 父 提 交 也 是 由 dumpl.dat 导 入 的 第 一 个 提交 。 


第 19 行 开始 定义 了 编号 为 “:8” 的 提交 。 该 提交 为 一 个 合并 提交 ， 
除了 在 第 25 行 设 定 了 第 一 个 父 提交 外 ， 还 由 第 26 行 给 出 了 第 二 个 父 提 


这 了 


Sa 


第 28 行 开始 定义 了 一 个 里 程 碑 。 里 程 牧 的 名 字 为 refstags/v1.0。 第 
29 行 指定 了 该 里 程 碑 对 应 的 提交 。 里 程 碑 的 说 明 由 第 31~33 行 的 指令 


给 出 。 


下 面 将 之 前 的 三 个 导入 文件 一 次 性 传递 给 git fast-import 来 创建 一 
个 新 版 本 库 ， 操 作 步 骤 如 下 。 


(1) 初始 化 版 本 库 import3。 


$mkdir-p/path/to/my/workspace/import3 
$cd/path/to/my/workspace/import3 
$git init 


(2) 调用 git fast-import 命 令 。 


$cat/path/to/file/dumpi1.dat/path/to/file/dump2.dat\ 
/path/to/file/dump3.dat|git fast-import 


(3) 查看 创建 的 版 本 库 的 日 志 。 
从 日 志 中 可 以 看 出 里 程 碑 v1.0 已 经 建立 在 最 新 的 提交 上 了 。 


$git log--oneline--graph--decorate 
*a47790e(HEAD, tag:refs/tags/vi1.0,master)Say helo to both users. 


|\ 

|*f486a44 Say helo to useri. 
*|73a6f27 User2's test commit. 
| 7 

*18f4310 My initial commit. 


理解 了 git-fast-import 的 导入 文件 格式 ， 针 对 特定 的 版 本 控制 系统 
开发 一 个 新 的 迁移 工具 就 不 是 难事 了 。Hg 的 迁移 工具 fast-export 束 是 
一 个 很 好 的 参照 。 


[1] 实际 上 Linux 版 本 控制 系统 迁移 到 Git 时 ， 最 早 也 没有 工具 帮助 迁移 
Bitkeeper 中 的 历史 代码 。 关 于 Linux 如 何 利 用 嫁接 (Grafts) 实现 新 旧 
Linux 版 本 控制 系统 的 对 接 参见 本 书 第 8 篇 第 41 章 “41.4 怒 接 和 替换 ”小 节 
的 相关 内 容 。 


[2] http://en.wikipedia.org/wiki/Here_document 


35.4 ”Git 版 本 库 整 理 
Git 提 供 了 太 多 武器 进行 版 本 库 的 整理 ， 可 以 将 一 个 Git 版 本 库 改 
头 换 面 成 另外 一 个 Git 版 本 库 。 


使 用 交互 式 变 基 操 作 ， 将 多 个 提交 合并 为 一 个 (参见 第 2 篇 第 12 


章 “12.3.3 时 间 旅 行 三 ”小 节 ) 。 


小 


使 用 StGit， 合 并 提交 及 更 改 提交 (参见 第 3 篇 第 20 章 "20.3.1 


StGit" 小 节 ) 。 


借助 变 基 操作 ， 抛 弃 部 分 历史 提交 (参见 第 2 篇 第 12 革 “12.4 于 茎 
历史 WN) 


使 用 子 树 合并 ， 将 多 个 版 本 库 整合 在 一 起 (参见 第 4 篇 “第 24 章 
子 树 合并 ”) 。 
使 用 git-subtree 插 件 ， 将 版 本 库 的 一 个 目录 拆 分 出 来 成 为 独立 版 本 


库 的 根 目录 (参见 第 4 篇 第 24 章 "24.5.4 git subtree split" 小 节 ) 。 


但 是 有 些 版 本 库 重 整 工作 如 果 使 用 上 面 的 工具 会 非常 困难 ， 而 采 
用 另外 一 个 还 没有 被 用 到 的 Git 命 令 git filter-branch 却 可 以 做 到 事 半 功 


倍 。 看 看 使 用 这 个 新 工具 来 实现 下 面 的 这 几 个 任务 是 多 么 的 简单 和 优 
美 。 


(1) 将 版 本 库 中 某 个 文件 彻底 删除 中。 即 凡是 有 该 文件 的 提交 


都 逐一 做 出 修改 ， 撤 出 该 文件 。 
$git filter-branch--tree-filter "rm-f filename'----all 


(2) 更 改 历史 提交 中 某 一 提交 者 的 姓名 及 邮件 地 址 。 


$gitfilter-branch--commit-filter' 
if["$GIT_AUTHOR_ NAME"="Xin Jiang"]; then 
GIT_AUTHOR_NAME="Jiang Xin" 
GIT_AUTHOR_EMAIL="jiangxin@ossxp.com" 
GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" 
GIT_COMMITTER_EMAIL="$GIT AUTHOR_EMAIL" 
f 

git commit-tree "$@"; 

'HEAD 


(3) 为 没有 包含 签名 的 历史 提交 添加 签名 。 


$git filter-branch-f--msg-filter' 
signed=false 

while read line; do 

if echo$line|lgrep-q Signed-off-by; then 
signed=true 

f 

echos$line 

done 

if!$signed; then 

echo" TT 

echo "Signed-off-by:YourName<yourQ@email.address>， 
f 

"HEAD 


通过 上 面 的 例子 ， 可 以 看 出 命令 git filter-branch 针 对 不 同 的 过 滤 履 
提供 可 执行 脚本 ， 从 不 同 的 角度 对 Git 版 本 库 进 行 重 构 。 该 命令 的 用 法 
如 下 : 


git filter-branch[--env-filter<command> ][--tree-filter <command 
>] 

[--index-filter<command> ][--parent-filter<command>] 

[--msg-filter<command>][--commit-filter <command>] 

[--tag-name-filter<command> ][--subdirectory-filter<directory 
>] 

[--prune-empty] 

[--original<namespace>][-d<directory>][-fl--force] 

[--][<rev-list options>...] 


这 条 命令 异 币 复 杂 ， 但 是 大 部 分 参数 是 用 于 提供 不 同 接口 的 ， 


此 还 是 比较 好 理解 的 。 


该 命令 最 后 的 < rev-list> 参数 提供 要 修改 的 版 本 范围 ， 如 有 果 省 略 
则 相当 于 HEAD 指 网 的 当前 分 文 。 也 可 以 使 用 --all 来 指 代 所 有 引用 ， 但 
征 要 在 --al 和 前 面 的 参数 间 使 用 分 隔 符 “--”。 


运行 git filter-branch 命 令 改写 分 文 之 后 ， 被 改写 的 分 文 会 在 
refs/original 中 对 原始 引用 做 备份 。 对 于 在 refs/original 中 已 有 备份 的 ， 
该 命令 拒绝 执行 ， 除 非 使 用 -f 或 --force 参 数 。 


其 他 的 后 面 可 这 命令 脚本 <command> 的 参数 (如 --env-filter < 
command>) ， 为 git filter-branch 命 令 提供 相应 的 编程 接口 ， 从 不 同 的 
角度 实现 对 Git 版 本 库 的 过 滤 。 下 面 针 对 各 个 过 滤 絮 分 别 进行 介绍 。 


35.4.1 


S 


环境 变量 过 滤 右 


参数 --env-filter 用 于 设置 一 个 环境 变量 过 滤 右 。 该 过 滤 右 用 于 修改 


环境 变量 ， 对 特定 的 环境 变量 的 修改 会 改变 提交 。 下 面 的 示例 可 用 于 
修改 作者 /提交 者 的 邮件 地 址 局 。 


$git 
an=" 
am=" 
cn=" 
cm=" 
if[" 
cm=" 
f 


filter-branch--env-filter' 
$GIT_AUTHOR_NAME" 
$GIT_AUTHOR_EMAIL" 
$GIT_COMMITTER_NAME" 
$GIT_COMMITTER_EMAIL" 
$cn"="Kanwei Li"]; then 
kanwei@gmail.com" 


if["$an"="Kanwei Li"]; then 
am="kanwei@gmail.com" 


f 


export GIT_AUTHOR_EMAIL=$am 
export GIT_COMMITTER_EMAIL=$cm 
1 


这 个 示例 和 本 市 一 开始 介绍 的 更 改作 者 /提交 者 信息 的 示例 功能 相 


同 ， 但 十 


使 用 了 不 同 的 过 滤 右 ， 你 可 以 根据 喜好 目 由 选择 。 


1] 这 里 使 用 的 命令 并 非 最 优 实现 ， 后 面 会 介绍 一 个 运行 得 更 快 的 命 


令 。 


[2| http://kanwei.com/code/2009/03/29/fixing-git-email.html 


35.4.2” 树 过 滤器 


参数 --tree-filter 用 于 设置 树 过 滤器 。 树 过 滤 如 会 将 每 个 提交 检 出 到 
特定 的 目录 中 (.git-rewrite/ 目 录 ， 或 者 用 -d 参 数 指定 的 目录 ) ， 针 对 
检 出 目录 中 文件 的 修改 、 添 加 、 删 除 会 改变 提交 。 注 意 此 过 滤器 名 
略 .gitignore， 因 此 对 检 出 目 孙 的 任何 修改 都 会 记录 在 新 的 提交 中 。 之 

前 介绍 的 文件 删除 就 是 一 例 ， 再 比如 对 文件 名 的 修改 : 
$git filter-branch--tree-filter' 


[-f oldfile]& Smv oldfile newfile||true 
'----all 


35.4.3 上 暂 存 区 过 滤器 


树 过 滤器 因为 要 将 每 个 提交 检 出 ， 因 此 非常 费时 ， 而 参数 --index- 
filter 给 出 的 暂 存 区 过 滤 右 则 没有 这 个 正点 。 如 有 果 将 之 前 使 用 树 过 滤器 
删除 文件 的 操作 换 成 用 暂 存 区 过 滤器 来 实现 ， 将 会 运行 得 更 快 。 


$git filter-branch--index-filter' 
git rm--cached--ignore-unmatch filename 
'----all 


其 中 参数 --ignore-unmatchi 上 git rm 命令 不 至 于 因为 暂 存 区 中 不 存在 
filename 文 件 而 失败 。 


35.4.4 父 玉 点 过 滤 货 


参数 --parent-filter 用 于 设置 父 忆 点 过 滤 磊 ， 该 过 滤 胡 用 于 修改 提交 
的 父 节 点 。 提 区 原始 的 父 节 点 通过 标准 输入 传 和 脚本， 而 脚本 的 输出 
将 作为 提交 的 新 的 父 节 点 。 父 市 后 参 数 的 格式 为 ， 如 琳 没 有 父 节 后 
(初始 提交 ) 则 为 空 ， 如 果 有 一 个 父 节 点 ， 参 数 为 "-p parent"; 如 有 果 是 


合并 提交 ， 则 有 多 个 父 下 点， 参数 为 "-p parent1-p parent2-p 


下 面 的 命令 将 当前 分 文 的 初始 提交 媒 接 到 < graft-id> 所 指向 的 提 


交 上 。 


$git filter-branch--parent-filter "Sed "s/^\$/-p<graft-id>/" ' 
HEAD 


如 有 果 不 是 将 初始 提交 (没有 父 提 交 ) 而 是 任意 的 一 个 提交 嫁接 到 
另外 的 提交 上 ， 可 以 通过 GIT_COMMIT 环 境 变量 对 提交 进行 判断 ， 更 


$git filter-branch--parent-filter\ 
'test$GIT_ COMMIT=<commit-id>&&\ 
echo"-p<graft-id>"||cat 

'HEAD 


关于 嫁接 ，Git 可 以 通过 配置 文件 .giyinfo/grafts 来 实现 上 ， 而 git 
filter-branch 命 令 可 以 基于 该 配置 文件 对 版 本 库 实 现 永 久 性 的 更 改 。 


$echo "$commit-id$graft-id">> .git/info/grafts 
$git filter-branch$graft-id,. .HEAD 


[1] 参见 第 8 篇 第 41 章 “41.4.1 提 交 嫁 接 ” 一 节 。 


35.4.5“ 提交 说 明 过 滤器 


参数 --msg-filter 用 于 设置 提交 说 明 过 滤 右 。 该 过 滤 右 用 于 改写 提 
交 说 明 。 原 始 的 提交 说 明 作为 标准 输入 传 入 脚本 ， 而 脚本 的 输出 则 作 
为 新 的 提交 说 明 。 


例如 ， 使 用 git-svn 命 令 从 Subversion 迁 移 过 来 的 Git 版 本 库 ， 默 认 
情况 下 在 提交 说 明 中 包含 git-svn-id: 字 样 的 说 明 ， 如 果 需 要 将 其 清除 ， 
可 以 不 必 重 新 迁移 ， 而 是 使 用 下 面 的 命令 重 写 提交 说 明 。 


$git filter-branch--msg-filter 'sed-e "/^git-svn-id:/d" '----all 


再 如 ， 为 最 新 的 10 个 提交 添加 "Acked-by:" 格 式 的 签名 。 


$git filter-branch--msg-filter' 

cat&& 

echo "Acked-by:Bugs Bunny<bunny@bugzilla.org>" 
'HEAD~10. .HEAD 


35 直 6， 本 到 过 谋生 


参数 --commit-filter 用 于 设置 提交 过 滤器 。 提 交 过 滤器 所 给 出 的 肢 
本 ， 在 版 本 库 重 整 过 程 的 每 次 提交 时 运行 ， 取 代 要 默认 执行 的 git 
commit-tree 命 令 。 不 过 一 般 情 况 下 会 在 脚本 中 调用 git commit-tree 命 
令 。 传 递 给 脚本 的 参数 格式 为 "<TREE_ID>[ (-p< 
PARENT_ COMMIT ID>) ...... ]"， 提 交 日 志 以 标准 输入 的 方式 传递 
给 脚本 。 脚 本 的 输出 是 新 提交 的 提交 ID。 作 为 扩展 ， 如 采 脚 本 输出 了 


多 个 提交 ID， 则 这 些 提交 ID 作 为 子 提交 的 多 个 父 节 上 后 。 


使 用 下 面 的 命令 ， 可 以 过 滤 挥 空 提 交 (合并 提交 除外 ) 。 


$git filter-branch--commit-filter' 
git_commit_non_empty_tree "$@" ' 


函数 git_commit _non_empty_tree 是 在 脚本 git-filter-branch 中 已 经 定 
义 过 的 函数 。 可 以 打开 文件 $ (git--exec-path) /git-filter-branch 查 看 。 


#if you run 'git commit_non_empty_tree "$@" ' in a commit 
filter, 

#it will skip commits that leave the tree untouched,commit the 
other. 

git_commit_non_empty_tree() 


{ 

if test$#=3&&test "$1"=$(git rev-parse "$3^{tree}"); then 
map "$3" 

else 

git commit-tree "$@" 

fi 


如 果 只 想 跳 过 某 个 用 户 (如 badboy) 的 提交 ， 而 无 论 该 提交 是 否 
为 空 ， 可 以 使 用 下 面 的 命令 


$git filter-branch--commit-filter' 
if["$GIT_AUTHOR_NAME"="badboy"]; 


then 

skip_commit "$@"; 
else 

git commit-tree "$@"; 
f'HEAD 


其 中 ， 函 数 skip_commit 也 是 在 脚 en 中 已 经 定义 好 
了 的 。 该 贸 数 的 作用 就 古 处 理 传递 给 提交 过 小 人 强 脚 本 的 参数 " <tree_id 
> -p parent1-p parent2...... "， 形 成 "parent1 parent2" 的 输出 。 参 见 Git 命 
令 脚 本 $ (git--exec-path) /git-filter-branch 中 相关 的 函数 。 


#if you run "Skip_commit "$@" ' in a commit filter,it will print 
the(mapped) 

parents,effectively skipping the commit. 

skip_commit() 


shift:; 
while[-n "$1"]; 


35.4.7 ”里程 修 名 字 过 滤 需 


参数 --tag-name-filter 用 于 设置 里 程 碑 名 字 过 滤 右 。 该 过 滤 需 也 坪 
经 常 要 用 到 的 过 滤器 。 上 面 介绍 的 各 个 过 滤 占 都 有 可 能 改变 提交 ID， 
如 果 在 原 有 的 提交 ID 上 建 有 里 程 碑 ， 可 能 会 随 之 更 新 ， 但 是 会 产生 大 
量 的 警告 日 志 ， 提 示 要 使 用 里 程 碑 过 滤器 。 里 程 碑 过 滤 右 脚本 以 原始 
里 程 碑 名 称 作为 标准 输入 ， 并 把 新 里 程 碑 名 称 作 为 标准 输出 。 如 采 不 
打算 变更 里 程 碑 的 名 称 ， 而 只 征 和 希望 里 程 牧 随 提交 而 更 新 ， 可 以 在 脚 
本 中 使 用 cat 命 令 。 例 如 ， 下 面 的 命令 中 同时 使 用 里 程 碑 名 字 过 滤器 和 
目录 树 过 滤器 。 


$git filter-branch--tree-filter' 
[-f oldfile]&&mv oldfile newfile||true 
'--tag-name-filter 'cat'----all 


在 前 面 的 里 程 碑 一 章 中 曾经 提 到 过 git branch 命 令 没 有 提供 里 程 碑 
重 命名 的 功能 ， 而 使 用 里 程 碑 名 字 过 滤器 可 以 实现 里 程 碑 的 重 命名 。 
下 面 的 的 示例 会 修改 里 程 碑 的 名 字 ， 将 前 弘 为 "old-prefix" 的 里 程 碑 改 
名 为 前 组 为 "new-prefix" 的 里 程 牧 。 
$git filter-branch--tag-name-filter 
oldtag="cat" 
newtag=${0ldtag#0old-prefix} 


if["$oldtag"!="$newtag"]; then 
newtag="new-prefix$newtag" 


echo$newtag 


注意 签名 里 程 碑 重 建 后 ， 因 为 签名 不 可 能 保持 ， 所 以 新 里 程 碑 会 
丢弃 签名 ， 成 为 一 个 普通 的 包含 说 明 的 里 程 碑 。 


35.4.8 子 目 孙 过 滤器 


参数 --subdirectory-filter 用 于 设置 子 目录 过 滤器 。 了 于 目录 过 滤 右 可 
以 将 版 本 库 的 一 个 子 目录 提取 为 一 个 新 版 本 库 ， 并 将 该 子 目 好 作为 版 
本 库 的 根 目 录 。 例 如 从 Subversion 转 换 到 Git 版 本 库 会 因为 参数 使 用 不 
当 ， 将 原 Subversion 的 主线 转换 为 Git 版 本 库 的 一 个 目录 trunk。 可 以 使 
用 git filter-branch 命 令 的 子 目录 过 滤 如 将 trunk 提 取 为 版 本 库 的 根 。 


$git filter-branch--subdirectory-filter trunk HEAD 


第 7 篇 ”Git 的 其 他 应 用 


Git 的 强大 和 别具一格 源 目 于 它 在 一 开始 整 没 有 按照 版 本 控制 系统 
的 思路 进行 设计 。 根 据 Linus Torvalds 自 己 的 说 法 :“ 我 真 的 是 从 一 个 文 
件 系 统 开 发 者 所 要 面 对 的 问题 的 角度 出 发 对 Git 进 行 设计 的 ( 嗨 ， 内 核 
是 我 开发 的 ) ， 并 且 我 真 的 对 于 建立 一 个 传统 的 SCM 系 统 没 有 一 点 兴 
趣 。11*Git 最 初 仅仅 是 一 个 可 对 内 容 进行 追踪 、 可 版 本 管理 的 另类 的 
文件 系统 ， 在 整个 社区 的 努力 下 ，Git 终 于 成 为 一 个 成 功 的 现代 的 版 本 
控制 系统 了 ， 而 基于 Git 的 其 他 应 用 才刚 刚 开 始 。 


维基 是 使 用 易于 理解 、“ 所 见 即 所 得 ”的 文本 来 编辑 网 页 ， 实 现 基 
于 Web 的 协同 著作 工具 ， 又 称 为 “web 的 版 本 控制 ”。 在 名 为 MZ Linux 
的 维基 网 站 上 轨 可 以 看 到 一 份 用 Git 作 为 后 端 实现 的 维基 列表 (大 部 分 
是 技术 上 的 试验 ) 。 


SpaghettiFS 项 目 中 党 试用 Git 作 为 数据 存储 后 端 ， 提 供 了 一 个 用 户 
空间 的 文件 系统 (FUSE,Filesystem in Userspace) 。 而 另外 的 一 些 项 目 
如 gitfs 入 可 以 直接 把 Git 版 本 库 挂 载 为 文件 系统 。 


下 面 的 章节 通过 几 个 典型 的 应 用 来 介绍 Git 在 版 本 控制 领域 之 外 的 
应 用 。 让 我 们 一 起 来 领略 Git 的 神奇 吧 。 


第 36 草 ”etckeeper 


Linux/Unix 的 用 户 对 /etc 目 孙 是 再 熟悉 不 过 了 ， 这 个 最 重要 的 目录 
中 保存 了 大 部 分 软件 的 配置 信息 ， 借 以 实现 对 软件 的 配置 乃至 对 整个 
系统 的 启动 过 程 进行 控制 。 对 于 Windows 用 户 来 说 ， 可 以 把 /etc 目 录 视 
为 Windows 中 的 注册 表 ， 只 不 过 是 文件 化 了 ， 易 管理 了 。 


这 么 重要 有 的 /etc 目 录 ， 如 果 其 中 的 文件 被 错误 编辑 或 删除 ， 将 会 损 
失 惨 重 。 有 一 个 名 为 etckeeper ”的 项 目 借用 分 布 式 版 本 控制 工具 
(如 : Git、Mercurial、Bazaar、Darcs) ， 可 以 帮助 实现 /etc 目 录 的 持 
续 备份 。 


那么 etckeeper 是 如 何 实现 的 呢 ? 下 面 承 以 Git 作 为 etckeeper 的 后 端 
为 例 进 行 说 明 ， 其 他 的 分 布 式 版 本 控制 系统 大 同 小 异 。 


将 /etc 目 录 Git 化 。 于 目录 /etc/.git 中 创建 Git 库 ， 将 /etc 目 录 作 为 工作 
区 。 与 系统 的 包 管理 器 (如 Debian/Ubuntu 的 apt、Redhat 上 的 yum 等 ) 
整合 。 一 旦 有 软件 包 安 装 或 删除 ， 束 对 /etc 目 录 下 的 改动 执行 提交 操 
作 。 


除了 能 够 记录 /etc 目 录 中 的 文件 内 容 外 ， 还 可 以 记录 文件 属性 等 元 
信息 。 因 为 /etc 目 孙 下 的 文件 的 权限 设置 往往 是 非常 重要 和 致命 的 。 


为 /etc 目 孙 已 经 成 了 一 个 Git 版 本 库 ， 可 以 用 Git 命 令 对 /etc 下 的 文 
件 进 行 操作 ， 查看 历史 ， 回 退 到 历史 版 本 ， 等 等 。 


也 可 以 将 /etc 克 隆 到 另外 的 主机 中 ， 实 现 双 机 备份 
36.1 ”安装 etckeeper 


安装 etckeeper 非 党 简单 ， 因 为 etckeeper 在 主流 的 Linux 发 行 版 中 都 
有 对 应 的 安装 包 。 使 用 相应 Linux 平 台 的 包 管理 器 (apt、yum) 即 可 安 


装 。 


在 Debian/Ubuntu 上 安装 etckeeper， 如 下 : 


$sudo aptitude install etckeeper 


安装 etckeeper 软 件 包 ， 还 会 自动 安装 一 个 分 布 式 版 本 控制 系统 工 
具 ， 除 非 已 经 安装 过 了 。 这 是 因为 etckeeper 需 要 使 用 一 个 分 布 式 版 本 
控制 系统 作为 存储 管理 后 端 。 在 Debian/Ubuntu 上 会 依据 下 面 的 优先 级 


进行 安装 : Git> Mercurial > Bazaar > Darcs。 


在 Debian/Ubuntu 上， 使 用 dpkg-s 命 令 查 看 etckeeper 的 软件 包 依 
赖 ， 就 会 看 到 这 个 优先 级 。 


$dpkg-s etckeeper|grep "^Depends" 


Depends:git-core(>=1:1.5.4)|git(>=1:1.7)|mercurial|bzr(>=1.4 
一 )| 
darcs, debconf(>=0.5)|debconf-2.0 


[1 | http://kerneltrap.org/node/4982 

[2| http://www.mzlinux.org/node/116 

[3] https://github.com/alex-morega/SpaghettiFS 
[4] http://code.google.com/p/gitfs/ 


[5] http://kitenet.net/~joey/code/etckeeper/ 


36.2 ”配置 etckeeper 


配置 etckeeper 首 先 要 选择 好 一 球 分 布 式 版 本 库 控制 工具 ， 如 Git， 
然后 用 相应 的 版 本 控制 工具 初始 化 /etc 目 隶 ， 并 做 一 次 提交 ， 具 体操 作 
过 程 如 下 。 


(1) 编辑 配置 文件 /etc/etckeeper/etckeeper.conf 。 


只 要 有 下 面 一 条 配置 就 够 了 。 告 诉 etckeeper 使 用 Git 作 为 数据 管理 


VCS="git" 


(2) 初始 化 /etc 目 录 。 即 将 其 Git 人 化。 执行 下 面 的 命令 ( 需 
root 用 户 的 身份 执行 ， 会 将 /etc 目 录 Git 人 化。 整个 过 程 可 能 会 
因为 要 对 /etc 下 的 文件 执行 gitadd， 文 件 又 太 多 ， 所 以 会 慢 一 些 


$sudo etckeeper init 


(3) 执行 第 一 次 提交 。 注 意 使 用 etckeeper 命 令 而 韭 Git 命 令 进行 


提交 。 


和 NM 


$sudo etckeeper commit "this is the frst etckeeper commit..." 


这 个 过 程 也 会 比较 慢 ， 主 要 是 因为 etckeeper 要 扫 摘 /etc 下 非 root 用 
尸 的 文件 及 特殊 权限 的 文件 并 进行 记录 。 别 起 了 Git 本 映 并 不 能 记录 文 
件 属 主 及 文件 权限 等 信息 。 


36.3 ”使 用 etckeeper 


实际 上 由 于 etckeeper 已 经 和 系统 的 包 管理 工具 (如 Debian/Ubuntu 
的 apbRedhat 上 的 yum 等 ) 进行 了 整合 ， 所 以 etckeeper 可 以 免 维 护 运 
行 。 即 一 旦 有 软件 包 安 装 或 删除 ， 对 /etc 目 录 下 的 改动 会 自动 执行 提交 
操作 。 


当然 也 可 以 随时 以 root 用 户 的 吴 份 执行 下 面 的 命令 对 /etc 目 孙 的 改 
动 进 行 手 动 提交 。 


$sudo etckeeper commit 


和 镜 下 的 工作 束 交 给 Git 了 。 可 以 在 /etc 目 录 中 执行 git log 、git show 
等 操作 。 但 要 注意 以 root 用 户 的 身份 运行 ， 因 为 /etc/.git 目 录 的 权限 不 
允许 普通 用 户 操 作 。 


第 37 章 。” Gistore 


当 了 解 了 etckeeper 之 后 ， 您 可 能 会 有 如 我 一 样 的 疑问 : “有 没有 像 
etckeeper 一 样 的 工具 ， 但 是 能 备份 任意 的 文件 和 目录 呢 ? 


我 在 Google 上 搜索 类 似 的 工具 无 果 ， 终 于 决定 动手 开发 一 个 ， 
为 无 论 是 我 还 是 我 的 客户 ， 都 需要 一 个 更 好 用 的 备份 工具 。 这 束 古 


Gistore ° 


Gistore=Git+Store 


2010 年 1 月 ， 我 在 公司 的 博客 上 发 表 了 Gistore 0.1 版 本 的 消息 ， 参 
见 : http://blog.ossxp.com/2010/01/406/。 并 将 Gistore 的 源 代码 托管 在 了 


Github 上 ， 参 见 : http://github.com/ossxp-com/gistore ° 


Gistore 的 出 现 是 受到 了 etckeeper 的 启发 ， 通 过 Gistore 用 户 可 以 把 
系统 中 任何 目 孙 的 数据 纳入 到 备份 中 ， 定 制 非常 简单 和 方便 。Gistore 
的 特点 如 下 : 


使 用 Git 作 为 数据 后 端 。 数 据 回 复 和 历史 查看 等 均 使 用 狼 悉 的 Git 


全 令 。 


对 


每 次 备份 即 为 一 次 Git 提 交 ， 文 持 文 件 的 添加 /删除 /修改 / 重 命名 


类 


每 次 备份 的 日 志 目 动 生 成 ， 内 容 为 此 次 修改 的 摘要 信息 。 


文 持 备 份 回 滚 ， 可 以 设 定 保存 备份 历史 的 天 数 ， 让 备份 的 空间 占 
用 维持 在 一 个 相对 稳定 的 水 平 上 。 


文 持 跨 着 备份 。 备 份 的 数据 源 可 以 来 目 任 何 卷 /目录 或 文件 。 


备份 源 如 果 已 经 Git 化 ， 也 能 够 备份 。 例 如 /etc 目 录 因 为 etckeeper 
被 Git 化 ， 仍 然 可 以 对 其 用 Gistore 进 行 备份 。 


多 机 异地 备份 非常 简单 ， 使 用 Git 克 隆 即 可 解决 。 可 以 采用 Git 协 
议 、HTTP， 或 者 更 为 安全 的 SSH 协 议 。 


说 明 : Gistore 目 前 只 能 运行 在 Linux、Mac OS X 等 类 Unix 操 作 系 
统 上 ， 因 为 在 备份 中 使 用 了 mount、umount 命 令 和 /或 FUSE 相 关 命 令 。 


37.1 ”Gistore 的 安装 


37.1.1 ”软件 依赖 


Gistore 运 行 时 需要 将 备份 项 逐一 挂 载 到 备份 工作 区 中 ， 因 此 需要 
安 逆 相应 的 挂 载 工具 。 


如 果 在 Linux 上 以 普通 用 户 的 吴 份 运行 Gistore， 或 者 在 Mac OS X 
上 执行 ， 则 需要 安装 bindfs 由 ， 以 便 能 够 将 备份 目录 挂 载 到 Gistore 工 
作 区 中 。 


如 果 在 Linux 上 以 管理 员 的 身份 运行 ， 则 可 以 不 安装 bindfs， 因 为 
Linux 下 的 mount--rbind 命 令 可 以 实现 备份 目录 到 Gistore 工 作 区 的 挂 
载 ee) 


如 果 以 普通 用 户 的 里 份 执行 ， 当 运行 挂 载 工具 遇 到 授权 问题 时 
如 果 安 装 并 且 正 确 配置 了 sudo 命 令 ， 则 会 自动 调用 sudo 命 令 执 行 。 


[1| http://code.google.com/p/bindfs/ 


37.1.2 ”从 源码 安装 Gistore 


从 源 代 码 安 故 和 运行 Gistore， 可 以 确保 安 逆 的 是 最 新 的 版 本 ， 
体操 作 步 又 如 下 。 


(1) 先 用 Git 从 Github 上 克隆 代码 库 。 


$git clone git://github.com/ossxp-com/gistore.git 


(2) 可 以 直接 在 克隆 出 的 源码 中 运行 Gistore 。 


$cd gistore 
$./gistore--help 


(3) 也 可 以 执行 setup.py 脚 本 ， 以 Python 软件 包 特 有 的 方式 安 


$sudo python setup.py install 
$which gistore 
/usr/local/bin/gistore 


37.1.3 ”用 easy_instal 安装 


Gistore 是 用 Python 语言 开发 的 ， 已 经 在 PYPI 上 注册 了 : 
http://pypi.python.org/pypi/gistore。 束 像 其 他 Python 软 件 包 一 样 ， 可 以 
使 用 easy_install 进 行 安装 ， 具 体操 作 过 程 如 下 。 


(1) 确保 您 的 机 器 上 已 经 安装 了 setuptools (1 。 


几乎 每 个 Linux 发 行 版 都 有 setuptools 软 件 包 ， 可 以 直接 用 包 管 理 器 
进行 安装 。 在 Debian/Ubuntu 上 可 以 使 用 下 面 的 命令 安装 setuptools: 


$sudo aptitude install python-setuptools 
$which easy_install 
/usr/bin/easy_install 


(2) 使 用 easy_install 命 令 安装 Gistore: 
$sudo easy_install-U gistore 


[1| http://peak.telecommunity.com/DevCenter/setuptools 


37.2 ”Gistore 的 使 用 


先 就 悉 一 下 Gistore 的 术语 。 


备份 库 : 通过 gistore init 命 令 创建 用 于 数据 备份 的 数据 仓库 。 备 份 
库 包 含 的 数据 有 : 


OGit 版 本 库 相 关 的 目录 和 文件 。 如 repo.git 目 录 (相当 于 .git 目 
录 ) 、.gitignore 文 件 等 。 


O Gistore 相 关 的 配置 。 如 .gistore/config 文 件 。 


备份 项 : 可 以 为 一 个 备份 库 指 定 任意 多 的 备份 项 目 。 
O 〇 例如 备份 /etc 目 录 ，/var/log 目 杂 等 。 


OO 备份 项 在 备份 库 的 .gistore/config 文 件 中 指定 ， 如 上 述 备 份 项 在 
配置 文件 中 的 写法 为 : 


[store "/etc"] 
enabled=true 
[store "/var/l10g"] 
enabled=true 


备份 任务 : 在 执行 Gistore 命 令 时 ， 可 以 指定 一 个 任务 或 多 个 任 


务 。 


任务 束 是 一 个 备份 库 的 路 径 ， 可 以 使 用 绝对 路 径 ， 也 可 以 使 用 相 
对 路 径 。 如 果 不 提 供 备份 任务 ， 即 不 指定 一 个 备份 库 路 径 ， 默 认 使 用 
当前 目录 。 除 了 使 用 路 径 外 ， 还 可 以 使 用 一 个 任务 别名 来 标识 备份 任 


O 〇 如 果 一 个 备份 库 在 ~/.gistore.d/tasks 目 录 ( 非 root 用 户 ) ， 或 
者 /etc/gistore/tasks 目 录 (root 用 户 ) 下 建立 了 一 个 符号 链接 ， 则 该 符号 
链接 的 名 称 就 是 这 个 备份 库 的 任务 别名 。 


O 通 过 任务 别名 的 机 制 ， 将 可 能 分 散在 磁盘 各 处 的 备份 库 汇 总 在 
一 起 ， 便 于 用 户 定位 备份 库 。 例 如 可 以 显示 所 有 在 ~/.gistore.d/tasks 目 
录 或 /etc/gistore/tasks 目 录 备 份 的 任务 列表 。 


37.2.1 创建 并 初始 化 备份 库 


在 使 用 Gistore 开 始 备份 之 前 ， 必 须 先 初始 化 一 个 备份 库 。 命 令 行 
格式 如 下 : 用 法 : gistore init[ 备 份 任务 ] 


初始 化 备份 库 的 示例 如 下 。 


将 当前 目录 作为 备份 库 进行 初 始 化 : 


$ mkdir backup 


$ cd backup 
$ gistore init 


将 指定 的 目录 作为 备份 库 进行 初始 化 : 

$sudo gistore init/backup/database 
当 一 个 备份 库 初 始 化 完毕 后 ， 包 含 下 列 文件 和 目录 : 
目录 repo.git， 存储 备份 的 Git 版 本 库 。 


文件 .gistore/config: Gistore 的 配置 文件 。 


目录 logs: Gistore 运 行 的 日 志 记 有 杂 。 


日 好 locks: Gistore 运 行 的 文件 锁 上 日 录 。 


37.2.2 ”Gistore 的 配置 文件 


在 每 一 个 备份 库 的 .gistore 目 隶 下 的 config 文 件 是 该 备份 库 的 配置 文 
件 ， 用 于 记录 Gistore 的 备份 项 内 容 ， 以 及 备份 回 深 设 置 等 。 


例如 下 面 的 配置 内 容 (为 描述 方便 添加 了 行 号 ) 


#Global config for all sections 
[main] 

backend=git 

backuphistory=200 
backupcopies=5 

rootonly=no 

version=2 


OROOORODP 


9 [default] 

10 keepemptydir=no 

11 keepperm=no 

12 

13 #Manage your backup list using:gistore add,gistore rm 
commands. 

14 [store"/opt/mailman/archives"] 

15 enabled=true 

16 [store"/opt/mailman/conf"] 

17 enabled=true 

18 [store"/opt/moin/conf"] 

19 enabled=true 


如 何 理解 这 个 配置 文件 呢 ? 


第 2 行 到 第 7 行 的 [main] 小 节 用 于 Gistore 的 全 局 设置 。 


第 3 行 设置 了 Gistore 使 用 的 SCM 后 端 为 Git， 这 是 目前 唯一 可 用 的 
设置 。 


第 4 行 设置 了 Gistore 的 每 一 个 历史 分 文保 存 的 最 多 的 提交 数目 ， 默 
认为 200 个 提交 。 当 超过 这 个 提交 数目 时 ， 进 行 备份 回 滚 。 

第 5 行 设置 了 Gistore 保 存 的 历史 分 文 数量 ， 默 认为 5 个 历史 分 文 。 
每 当 备 份 回 滩 时 ， 会 将 备份 主线 保存 到 名 为 gistore/1 的 历史 分 文中 。 


第 6 行 设置 非 root_only 模 式 ， 如 果 开 局 root_only 模 式 ， 则 只 有 root 
用 户 能 够 执行 此 备份 库 的 备份 。 


第 7 行 设置 了 Gistore 备 份 库 的 版 本 。 


第 9 行 开始 的 [default] 小 节 设置 后 面 的 备份 项 小 节 的 默认 设置 。 在 
后 面 的 [store..……….] 小 节 可 以 覆盖 此 默认 设置 。 


第 10 行 设置 是 否 保留 空 目 永 。 暂 未 实现 。 


第 11 行 设置 是 否 保持 文件 属 主 和 权限 。 和 暂 未 实现 。 


第 14 行 到 第 19 行 是 备份 项 小 站 ， 人 小节 名 称 以 store 开 始 ， 后 面 的 部 
分 即 为 备份 项 的 路 人 径 。 例 如 [store/opt/mailman/archives] 的 含义 是 : 要 
对 /opt/mailman/archives 目 隶 进行 备份 。 


37.2.3 ”Gistore 的 备份 项 管理 


请 不 要 直接 编辑 .gistore/config 文 件 ， 以 免 因 为 格式 错误 导致 
Gistore 无 法 运行 。 可 以 通过 git config 命 令 对 该 文件 进行 操作 ， 因 为 实 
际 上 这 个 文件 就 是 用 git config 命 令 创 建 的 。 


$git config-f.gistore/config store./some/dir.enabled false 
$git config-f.gistore/config-1 


Gistore 提 供 了 几 个 子 命令 ， 对 备份 项 进行 管理 。 


1. 添 加 备份 项 


进入 备份 库 目 未 ， 执 行 下 面 的 命令 ， 添 加 备份 项 /some/dir。 注 意 
备份 项 要 使 用 全 路 径 ， 即 要 以 “开始 。 


$gistore add/some/dir 


2. 删 除 备份 项 


进入 备份 库 目 隶 ， 执行 下 面 的 命令 ， 则 删除 备份 项 /some/dir。 第 
一 次 执行 该 命令 停 用 该 备份 项 的 备份 ， 即 将 store./some/direnabled 配 置 
变量 设置 为 false。 当 第 二 次 执行 该 删除 命令 ， 则 彻底 删除 该 备份 项 。 


$gistore rm/some/dir 


3. 查 看 备份 项 


进入 备份 库 目 未 ， 执 行 gistore status 命 令 ， 显 示 备 份 库 的 设置 及 备 
份 项 列表 。 


$gistore Status 

Task name:system 
Directory:/data/backup/gistore/system 
Backend:git 

Backup capability:200 commits*5 copies 
Backup list: 

/backup/databases(--) 

/backup/ldap(--) 
/data/backup/gistore/system/.gistore(--) 
/etc(AD) 

/opt/cosign/conf(--) 
/opt/cosign/factor(--) 
/opt/cosign/1ib(--) 

/opt/gosa/conf(--) 

/opt/ossxp/conf(--) 

/opt/ossxp/ssl(--) 


从 备份 库 的 状态 输出 可 以 看 到 : 
备份 库 有 一 个 任务 别名 为 system 。 


备份 库 的 路 径 是 /data/backup/gistore/system 。 


备份 的 容量 是 200*5， 如 果 按 每 天 备份 一 次 来 计算 ， 总 共 可 以 保存 
1000 天 ， 差 不 多 3 年 的 数据 备份 。 


在 备份 项 列表 ， 可 以 看 到 多 达 10 个 备份 项 。 


每 个 备份 项 后 面 的 括号 代表 其 备份 选项 ， 其 中 /etc 的 备份 选项 为 
AD。A 代 表 记 有 杂 并 保持 授权 ，D 的 含义 是 保持 空 目 隶 。 


37.2.4 ”执行 备份 任务 


执行 备份 任务 非常 和 测 单 ; 
进入 到 备份 库 根 目录 下 ， 执 行 : 

$sudo gistore commit-m "The reason for backup" 
或 者 在 命令 行 上 指定 备份 库 的 路 径 : 

$sudo gistore ci/backup/database 


说 明 : ci 为 commit 命 令 的 简称 。 


37.2.5 查看 备份 日 志 


备份 库 中 的 repo.git 束 是 备份 数据 所 在 的 Git 库 ， 这 个 Git 库 是 一 个 
不 市 工作 区 的 梨 库 。 可 以 对 其 执行 git log 命 令 来 查看 备份 日 志 。 


因为 并 非 采 用 通常 的 .git 作 为 版 本 库 名 称 ， 而 且 不 带 工作 区 ， 需 
通过 --git-dir 参 数 指定 版 本 库 的 位 置 ， 如 下 


$git--git-dir=repo.git log 


Gistore 提 供 了 一 个 log 子 命令 ， 能 更 方便 地 显示 备份 日 志 。 该 子 命 
令 实际 是 对 上 面 的 Git 命 令 的 封闭 ， 因 此 可 以 同 其 传递 任何 git log 命 令 
可 以 理解 的 参数 。 如 : 


$gistore lo0g--pretty=oneline 


下 面 是 我 公司 内 的 服务 器 每 日 备份 的 日 志 厂 断 : 


commit 9d16b5668c1a09f6fa0b0142c6d34f3cbb33072f 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Aug 5 04:00:23 2010+0800 

Changes summary:total=423,A:407,D:1,M:15 
A=>etc/gistore/tasks/Makefile, 
opt/cosign/l1ib/share/locale/cosign.pot, 
opt/cosign/l1ib/templates-local.old/expired _ error.html, 
opt/cosign/l1ib/templates-local.old3/error.html, 
opt/cosign/l1ib/templates/inc/en/0020_scm.html,...402 more... 
D=>etc/gistore/tasks/default 


M=> .gistore/config,etc/gistore/tasks/gosa, 

etc/gistore/tasks/testlink,etc/group,etc/gshadow-,...10 more... 

commit 0901b6bce2e4ee2f8cda57ceb3c4dbodb9eb9obbed 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:wed Aug 4 04:01:09 2010+0800 

Changes summary:total=8,A:7,M:1 

A=>backup/databases/blog_bj/blog_bj.sql, 

backup/databases/ossxp/mysql.sql,backup/databases/redmine/redmin 
e.sql,backup/databases/testlink/testlink-1.8.sql, 

backup/databases/testlink/testlink.sql,...2 more... 

M=> .gistore/config 

commit 15ef2e88f33dfa7dfb04ecbcdb9e6b2a7c4e6b00 

Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Aug 3 16:59:12 2010+0800 

Changes Summary :total=2665,A:2665 

A=> .gistore/config,etc/apache2/sites-available/gems,etc/group-, 

etc/pam.d/dovecot,etc/ssl/certs/0481cb65.0,...2660 more... 


从 上 面 的 日 志 可 以 看 出 : 


备份 发 生 在 晚上 4 点 钟 左右 。 这 是 因为 备份 是 在 晚上 目 动 执行 的 。 


ID 为 "15ef2e8" 的 提交 是 一 次 手动 提交 。 从 提交 说 明 中 可 以 看 到 添 
加 了 2665 个 文件 。 最 新 的 备份 ID 为 "9d16b56"， 其 中 既 有 文件 添加 
(A) ， 又 有 文件 删除 \D) ， 还 有 文件 变更 (M) ， 会 随机 各 选择 5 
个 文件 出 现在 提交 日 志 


如 有 果 想 查看 详细 的 文件 变更 列表 ， 使 用 下 面 的 命令 


$gistore 10g-1--stat 9d16b56 

commit 9d16b5668c1a09f6fao0b0142c6d34f3cbb33072f 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Aug 5 04:00:23 2010+0800 

Changes summary:total=423,A:407,D:1,M:15 


A=>etc/gistore/tasks/Makefile, 
opt/cosign/l1ib/share/locale/cosign.pot, 
opt/cosign/l1ib/templates- 

local.old/expired_ error.html,opt/cosign/l1ib/templ 
D=>etc/gistore/tasks/default 
M=> .gistore/config,etc/gistore/tasks/gosa, 
etc/gistore/tasks/testlink,etc/group,etc/gshadow-,...10 more... 
.gistore/config|4+ 
backup/databases/redmine/redmine.sql|44+- 
etc/apache2/include/redmine/redmine.conf |40+- 
etc/gistore/tasks/Makefile|1+ 
etc/gistore/tasks/default|1- 
etc/gistore/tasks/gosal|2+- 


opt/gosa/conf/sieve-spam.txt|6+ 
opt/gosa/conf/sieve-vacation.txt|4+ 


opt/ossxp/conf/cron.d/ossxp-backup|8+- 
423 files changed,30045 insertions(+),51 deletions(-) 


在 备份 库 的 logs 目 孙 下 ， 还 有 一 个 备份 过 程 的 日 志文 件 
logs/gitstore.l1og。 记 录 了 每 次 备份 的 诊断 信息 ， 主 要 用 于 调试 Gistore 。 


37.2.6 查看 及 恢复 备份 数据 


所 有 的 备份 数据 ， 实 际 上 都 在 repo.git 目 录 指 向 的 Git 库 中 维护 。 如 
何 获取 这 些 备份 数据 呢 ? 

1. 克 隆 方式 检 出 

执行 下 面 的 命令 ， 克 隆 裸 版 本 库 repo.git: 


$git clone repo.git data 


进入 data 目 录 ， 束 可 以 以 Git 的 方式 查看 历史 数据 ， 以 及 恢复 历史 
数据 。 当 然 恢 复出 来 的 历史 数据 还 要 找 贝 到 原始 位 置 才能 真正 实现 数 
据 的 恢复 。 


2. 分 离 的 版 本 库 和 工作 区 方式 检 出 


还 有 一 个 稍微 复 洒 点 的 方法 ， 就 是 既然 版 本 库 已 经 在 repo.git 中 
了 ， 可 以 直接 利用 它 ， 避 人 免 殉 隆 导致 空间 上 的 浪费 ， 尤 其 是 当 备 份 库 
异常 庞大 的 时 候 ， 具 体操 作 过 程 如 下 。 


(1) 创建 一 个 工作 目录 ， 如 export 。 


$mkdir export 


(2) 设置 环境 变量 ， 制 定 版 本 库 和 工作 区 的 位 置 。 注 意 使 用 绝对 
路 径 。 


$export GIT_DIR=/path/to/repo.git 
$export GIT_WORK_TREE=/path/to/export 


(3) 然后 就 可 以 进入 export 目 录 ， 执 行 Git 操 作 了 。 


$cd/path/to/export 
$git status 
$git checkout. 


37.2.7 备份 回 深 及 设置 


我 在 开发 Gistore 时 ， 最 碾 烦 的 束 古 备份 历史 的 管理 。 如 采 不 对 备 
份 历 史 进 行 回 深 ， 必 然 会 导致 提交 越 来 越 多 ， 备 份 空间 占用 越 来 越 
大 ， 直 至 磁 强 空间 占 满 。 


最 早 的 想法 是 使 用 git rebase 命 令 ， 即 将 准备 丢弃 的 早期 备份 历史 
压缩 为 一 个 提交 ， 然 后 后 面 的 提交 再 变 基 到 压缩 后 的 提交 之 上 ， 这 样 
忠实 现 了 对 历史 提交 的 丢弃 。 但 是 这 样 的 操作 有 既 费时 ， 叉 复 光 。 忽 然 
有 一 天 有 灵机 一 动 ， 为 什么 不 用 分 文 来 保留 回 滚 的 数据 ?” 至 于 备份 主线 
(master 分 文 ) 则 从 一 个 新 的 提交 开始 重建 。 


回 滚 后 master 分 文 如 何 从 一 个 痢 提 交 开 始 呢 ? 较 早 的 实现 是 直接 
重 置 到 一 个 空 提交 (gistore/0) 上 ， 但 是 这 样 会 导致 接 下 来 的 备份 非常 
耗 时 。 最 新 的 实现 是 使 用 git hash-object 命 令 ， 直 接 对 回 滚 前 master 分 
文 的 最 狐 提 区 进行 改造 ， 创 造 出 一 个 没有 父 提交 的 痢 提 区。 


备份 回 秘 的 具体 实现 过 程 是 : 


(1) 每 次 备份 ， 都 提交 在 Git 库 的 分 支 master 上 。 


(2) 当 Git 库 的 master 分 支 的 提交 数量 达到 规定 的 阔 值 (默认 
200) 时 ， 则 从 master 分 支 建 立新 的 分 支 ， gistore/1。 如 果 已 有 分 支 


gistore/1 则 建立 分 文 gistore/2， 依 次 类 推 。 


| 


(3) 然后 master 分 支 重 置 到 一 个 用 git hash-object 命 令 基于 当前 


新 提交 建立 的 一 个 新 提交 (没有 父 提 交 ) 。 


(4) 如 果 保 存 备份 历史 的 分 支 数 量 达到 预 移 设 定 的 国 值 (默认 5 
个 分 支 )， 分 支 依 次 回 滚 。 


用 分 支 gistore/2 重 置 分 支 gistore/1， 用 分 文 gistore/3 重 置 分 支 
gistore/2， 依 次 类 推 。 即 保存 最 早 备 份 历史 的 分 文 gistore/1 被 丢 痉 。 


基于 分 文 master 建 立 分 文 gistore/5。 


(5) 当 分 支 重 置 及 回 深 发 生 后 ， 对 备份 库 的 远程 数据 同步 不 会 有 
什么 影响 ， 传 输 的 数据 量 也 仪 是 新 增 备份 和 上 一 次 备份 的 差异 。 


虽然 备份 历史 由 于 master 分 文 的 重 置 被 分 割 为 多 个 独立 的 片段 ， 
但 是 因为 使 用 了 Git 提 交 嫁 接 凯 的 功能 ， 执 行 gistore log 可 以 看 到 master 
分 支 及 其 他 形 如 gistore/N 分 文 的 所 有 提交 日 志 。 奥 秘 束 在 
repo.git/info/grafts 文 件 。 


[1] 第 8 篇 第 41 章 “41.4.h1 提交 嫁接 ”小 节 。 


37.2.8 注册 备份 任务 别名 


因为 Gistore 可 以 在 任何 目 孙 下 创建 备份 任务 ， 用 户 很 难 确 定 当前 
到 发 存在 多 少 个 备份 库 ， 因 此 需要 提供 一 个 机 制 ， 让 用 户 能 够 对 备份 
库 进 行 统 一 管理 。 还 有 一 个 原因 ， 驶 是 在 使 用 Gistore 时 知 使 用 长 长 的 
备份 库 路 径 作 参 数 会 显得 非常 笨拙 。 任 务 别名 束 是 用 来 解决 这 些 问 题 
9。 


任务 别名 实际 上 就 是 备份 库 在 用 户主 目录 下 的 ~/.gistore.d/tasks 目 
录 ( 非 管理 员 ) 或 /etc/gistore/tasks 目 孙 (管理 员 ) 下 创建 的 符号 连 
接 。 例 如 : 管理 员 在 /etc/gistore/tasks 目 如下 创建 备份 库 的 符号 链接 : 


$sudo ln-s/home/jiangxin/Desktop/mybackup/etc/gistore/tasks/jx 
$sudo ln-s/backup/database/etc/gistore/tasks/db 


然后 殉 可 以 用 别名 来 访问 对 应 的 备份 库 ， 简 化 备份 命令 : 


$sudo gistore commit jx 
$sudo gistore commit db 


查看 一 份 完 整 的 备份 列表 也 非常 简单 ， 执 行 gistore list 命 令 即 可 。 


$sudo gistore list 
db:/backup/database 
jxX:/home/jiangxin/Desktop/mybackup 


当 gistore list 命 令 后 面 指 定 某 个 任务 列表 时 ， 相 当 于 执行 gistore 


status 命 令 ， 碍 看 备份 状态 信息 : 


$sudo gistore list db 


可 以 用 一 条 命令 对 所 有 的 任务 别名 执行 备份 : 


$sudo gistore commit-all 


37.2.9 ”自动 备份 : crontab 


在 /etc/cron.d/ 目 录 下 创建 一 个 文件 ， 如 /etc/cron.d/gistore， 包 含 如 
下 内 容 : 


##gistore backup 
© 4***root/usr/bin/gistore commit-all-vvvv 


这 样 每 天 凑 晨 4 点 ， 束 会 以 root 用 户 的 身份 执行 gistore commit-all 命 


令 。 参 数 -vvvv 的 含义 是 提供 更 多 的 诊断 输出 。 


将 Gistore 备 份 库 在 /etc/gistore/tasks 目 录 下 创建 一 个 符号 链接 ， 就 
可 以 每 天 目 动 启动 相应 Gistore 备 份 库 的 备份 。 


37.3 ”Gistore 双 机 备份 


Gistore 备 份 库 的 主体 就 是 repo.git， 即 一 个 Git 库 。 可 以 架设 一 个 
Git 服 务 器 ， 远 程 主 机 通过 克隆 该 Git 服 务 器 的 备份 库 实现 双 机 备份 其 
至 古 异 地 备份 。 而 且 最 酶 的 是 ， 整 个 数据 同步 的 过 程 是 可 视 的 、 快 速 
的 和 无 痛 的 ， 感 谢 伟 大 而 又 神奇 的 Git 。 


最 好 使 用 公 钥 认证 的 、 基 于 SSH 的 Git 服 务 器 架设 ， 一 来 可 以 实现 
无 口令 的 数据 同步 ， 二 来 增加 了 安全 性 ， 因 为 备份 数据 中 可 能 包含 敏 
感 数据 。 


还 有 可 以 直接 利用 现成 的 /etc/gistore/tasks 目 录 作 为 版 本 库 的 根 。 
当然 还 需要 在 架设 的 Git 服 务 器 上 ， 使 用 一 个 地 址 变换 的 小 穿 门 。 
Gitosis 服 务 器 软件 的 地 址 变换 魔法 正好 可 以 帮助 实现 ， 请 参见 第 5 篇 第 
31 章 “31.5” 轻 量 级 管理 的 Git 服 务 ”。 


第 38 章 ”补丁 中 的 二 进 制 文 件 


有 的 时 候 ， 需 要 将 代码 的 改动 以 补丁 文件 的 方式 进行 传递 ， 最 终 
合并 至 版 本 库 。 例 如 直接 在 软件 部 署 目 孙 内 进行 改动 ， 再 将 改动 传送 
到 开发 平台 。 或 者 古 因为 在 某 个 开源 软件 的 官方 版 本 库 中 没有 提交 权 
限 ， 需 要 将 目 己 的 改动 以 补丁 文件 的 方式 提供 给 官方 。 


关于 补丁 文件 的 格式 ， 补 丁 的 生成 和 应 用 在 第 3 篇 的 “第 20 章 补丁 
文件 交互 ”当中 已 经 进行 了 详细 介绍 ， 使 用 的 是 git format-patch 和 git am 
命令 ,但 这 两 个 命令 仅 对 Git 库 有 效 。 如 采 没 有 使 用 Git 对 改动 进行 版 
本 控制 ， 而 仅仅 古 两 个 目录 : 一 个 改动 前 的 目录 和 一 个 改动 后 的 目 
录 ， 大 部 分 人 会 选择 使 用 GNU 的 diff 命 令 及 patch 命 令 实现 补丁 文件 的 
生成 和 补丁 的 应 用 。 


但 是 GNU 的 diff 命 令 (包括 很 多 版 本 控制 系统 ， 如 SVN 的 svn diff 
命令 ) 生成 的 差异 输出 有 一 个 非常 大 的 不 足 或 者 说 漏洞 ， 就 是 差异 输 
出 不 支持 二 进 制 文件 。 如 果 生 成 了 新 的 二 进 制 文件 〈 如 图 片 ) ， 或 者 
二 进 制 文件 发 生 了 变化 ， 在 差异 输出 中 无 法 体现 ， 当 这 样 的 差异 文件 
被 导出 ， 应 用 到 代码 树 中 ， 会 发 现 二 进 制 文件 或 二 进 制 文件 的 改动 丢 
x 


Git 突 破 了 传统 差异 格式 的 限制 ， 通 过 引入 新 的 差异 格式 ， 实 现 了 
对 二 进 制 文件 的 支持 。 并 且 更 为 神奇 的 是 ， 不 必 使 用 Git 版 本 库 对 数据 
进行 维护 ， 可 以 直接 对 两 个 普通 目录 进行 Git 方 式 的 差异 比较 和 输出 。 


38.1 Git 版 本 库 中 二 进 制 文件 变更 的 支持 


1. 创 建文 持 二 进 制 文件 的 补丁 


对 Git 工 作 区 的 修改 进行 差异 比较 (git diff--binary) ， 可 以 输出 二 
进 制 的 补丁 文件 。 包 含 二 进 制 文件 差异 的 补丁 文件 可 以 通过 git apply 命 
令 应 用 到 版 本 库 中 。 可 以 通过 下 面 的 示例 看 看 Git 的 补丁 文件 是 如 何 对 
二 进 制 文件 提供 支持 的 ， 具 体操 作 过 程 如 下 。 


(1) 首先 建立 一 个 空 的 Git 有 版 本 库 。 


$mkdir/tmp/test 

$cd/tmp/test 

$git init 

initialized empty Git repository in/tmp/test/.git/ 
$git commit--allow-empty-m initialized 
[master(root-commit)2ca650c |initialized 


(2) 然后 在 工作 区 创建 一 个 文本 文件 readme.txt， 以 及 一 个 二 进 
制 文件 binary.data。 二进制 的 数据 是 从 系统 中 的 二 进 制 文件 /bin/ls 读 取 
而 来 的 ， 当 然 可 以 用 任何 其 他 的 二 进 制 文件 代替 。 


$echo hello>readme.txt 


$dd if=/bin/ls of=binary.data count=1 bs=32 
记录 了 1+0 的 读 入 

记录 了 1+0 的 写 出 
32 字 节 (32 B) 已 复制 ,9.0001062 秒 ,301 kB/ 秒 


注 : 拷贝 /bin/ls 可 执行 文件 (二进制 ， 的 前 32 个 字 节 作为 
binary.data 文 件 。 


(3) 如 果 执行 git diff--cached 则 看 到 的 是 未 扩展 的 差异 格式 。 


$git add. 

$git diff--cached 

diff--git a/binary.data b/binary.data 
new file mode 100644 

index 0000000. .dc2e37f 

Binary files/dev/null and b/binary.data differ 
diff--git a/readme.txt b/readme.txt 
new file mode 100644 

index 0000000. .ce01362 

---/dev/null 

+++b/readme. txt 

Q@@-0,0+1@@ 

+hello 


可 以 看 到 对 于 binary.data， 此 差异 文件 没有 给 出 差异 内 容 ， 而 只 是 


一 行 "Binary files......and......differ" 。 


(4) 再 执行 git diff--cached--binary 试 试看 ， 即 增加 了 参数 -- 


binary ° 


$git diff--cached--binary 

diff--git a/binary.data b/binary.data 
new file mode 100644 

index 


0000000000000000000000000000000000000000 , .dc2e37f81e0fa88308bec4 
8cd5195b6 

542e61a20 

GIT binary patch 

literal 32 

bcmb<-^>JfjwMqH=CISkOSHCROOW1UNGBE; C 

literal 0 

HcmV? d00001 

diff--git a/readme.txt b/readme.txt 

new file mode 100644 

index 0000000. .ce01362 

---/dev/null 

+++b/readme .txt 

Q@@-0,0+1@@ 

+hello 


看 到 了 了 吗 ， 此 差异 文件 给 出 了 二 进 制 文件 binary.data 差 异 的 内 容 ， 
并 且 差 异 内 容 经 过 base85 上 文本 化 了 。 


(5) 提交 后 ， 用 新 的 内 容 履 盖 binary.data 文 件 。 


$git commit-m "new text file and binary file" 
[master 7ab2d01]new text file and binary file 
2 files changed,1 insertions(+),0 deletions(-) 
create mode 100644 binary.data 

create mode 100644 readme.txt 

$dd if=/bin/ls of=binary.data count=1 bs=64 
记录 了 1+0 的 读 入 

记录 了 1+0 的 写 出 
64 字 节 (64 B) 已 复制 , 0.00011264 秒 , 568 kB/ 秒 

$git commit-a-m "change binary.data." 

[master a79bcbe]jchange binary.data. 

1 files changed,0 insertions(+),0 deletions(-) 


(6) 再 来 看 看 更 改 后 的 二 进 制 文件 的 新 差异 格式 。 


$git show HEAD--binary 
commit a79bcbe50c1d278db9c9db8e42d9bc5bc72bf031 
Author:Jiang Xin<jiangxin@ossxp.com> 


Date:Sun Oct 10 19:22:30 2010+0800 

change binary.data. 

diff--git a/binary.data b/binary.data 

index 

dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8 


168cb716f 


bc2a127c3 100644 

GIT binary patch 

delta 37 

hcmY#zn4qBGzyJX+< }pH93=9qo77QFfQiegAORUZd1MdI; 
delta 4 

LcmZ=zn4kav0O;B;E 


(7) 更 简单 的 ， 使 用 git format-patch 命 令 ， 直 接 将 最 近 的 两 次 提 


交 导 出 为 外 文件。 


00 : 


$git format-patch HEADAA^ 
0001-new-text-file-and-binary-file,patch 
0002-change-binary.data.patch 


上 毫 无 疑问 ， 这 两 个 补丁 文件 都 包含 了 对 二 进 制 文件 的 支持 。 


$cat 0002-change-binary.data.patch 
From a79bcbe50c1d278db9c9db8e42d9bc5bc72bf031 Mon Sep 17 


00:00 2001 


From:Jiang Xin<jiangxin@ossxp.com> 

Date:Sun,10 Oct 2010 19:22:30+0800 

Subject:[PATCH 2/2]change binary.data. 

binary.datalBin 32->64 bytes 

1 files changed,0 insertions(+),0 deletions(-) 

diff--git a/binary.data b/binary.data 

index 

dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8 


168cb716f 


bc2a127c3 100644 

GIT binary patch 

delta 37 
hcmY#zn4qBGzyJX+<}pH93=9qo77QFfQiegAORUZd1MdI; 
delta 4 


LcmZ=zn4kav0;B;E 


tl 


2. 应 用 包含 二 进 制 文件 差异 的 补丁 


应 用 包含 二 进 制 文件 差异 的 补丁 ， 不 能 使 用 GNU patch 命 令 ， 
为 前 面 曾经 说 过 GNU 的 dif 和 patch 不 支持 二 进 制 文 件 的 补丁 ， 当 然 也 
不 支持 Git 的 新 的 补丁 格式 。 将 Git 格 式 的 补丁 应 用 到 代码 树 ， 只 能 使 
用 Git 命 令 ， 即 git apply 命 令 。 

接着 前 面 的 例子 。 首 和 完 将 版 本 库 重 置 到 最 近 两 次 提交 之 前 的 状 


仿 ， 即 丢弃 最 近 的 两 次 提交 ， 然 后 将 两 个 促 丁 都 合并 到 代码 树 中 ， 具 
体操 作 步 又 如 下 。 


(1) 重 置 版 本 库 到 两 次 提交 之 前 的 状态 。 


$git reset--hard HEADAA^ 

HEAD is now at 2ca650c initialized 

$1s 

0001-new-text-file-and-binary-file.patch 0002-change- 
binary.data.patch 


(2) 使 用 git apply 应 用 补丁 . 


$git apply 0001-new-text-file-and-binary-file.patch 
0002-change-binary.data.patch 


(3) 可 以 看 到 64 字 节 长 度 的 binary.data 又 回来 了 。 


$1s-1 

总 用 量 16 

-rw-r--r--1 jiangxin jiangxin 754 10 月 10 19:28 
0001-new-text-file-and-binary-file.patch 

-rw-r--r--1 jiangxin jiangxin 524 10 月 10 19:28 
0002-change-binary.data.patch 

-rw-r--r--1 jiangxin jiangxin 64 10 月 10 19:34 binary.data 
-rw-r--r--1 jiangxin jiangxin 6 10 月 10 19:34 readme .txt 


(4) 最 后 不 要 忘 了 提交 。 


$git add readme.txt binary.data 

$git commit-m "new text file and binary file from patch files." 
[master 7c1389f]jnew text file and binary file from patch files. 
2 files changed,1 insertions(+),0 deletions(-) 

create mode 100644 binary.data 

create mode 100644 readme.txt 


Git 对 补丁 文件 的 扩展 ， 实 际 上 不 只 是 增加 了 二 进 制 文件 的 支持 ， 

还 提供 了 对 文件 重 命名 (rename from 和 rename to 指令 ) 、 文 件 拷贝 
(copy from 和 copy to 指令 ) 、 文 件 删 除 (deleted file 指 令 ) 及 文件 权 
限 (new fle mode 和 new mode 指 令 ) 的 支持 。 


[1] Git 源 代码 diff.c 的 emit_binary_diff_body 芳 数 。 


38.2 ”对 非 Git 版 本 库 中 二 进 制 文件 变更 的 文 持 


不 在 Git 版 本 库 中 的 文件 和 目录 可 以 比较 生成 Git 格 式 的 补丁 文件 
吗 ， 以 及 可 以 执行 应 用 补丁 的 操作 吗 ? 


是 的 ，Git 的 dif 命 令 和 apply 命 令 文 持 对 非 Git 版 本 库 /工作 区 进行 的 
操作 。 但 是 1.7.3 以 前 版 本 的 Git 的 git apply 命 令 有 一 个 Bug， 这 个 Bug 导 
致 目前 的 git apply 命 令 只 能 应 用 patch level (补丁 文件 前 级 级 别 ) 为 1 的 
补丁 。 我 已 经 将 改正 这 个 Bug 的 补丁 文件 提交 到 了 Git 开 发 列表 中 由 ， 
但 有 其 他 人 先 于 我 修正 了 这 个 Bug。 不 管 最 终 的 修正 方法 如 何 ， 在 新 
版 本 的 Git 中 ， 这 个 问题 应 该 已 经 解决 。 


下 面 的 示例 将 演示 如 何 对 非 Git 版 本 库 使 用 git diff 和 git patch 命 令 。 
首先 准备 两 个 目录 ， 一 个 为 hello-1.0 目 录 ， 在 其 中 创建 一 个 文本 文件 
am oi DA 


$mkdir hello-1.0 

$echo hello>hello-1.0/readme. txt 

$dd if=/bin/l1s of=hello-1.0/binary.dat count=1 bs=32 
记录 了 14+0 的 读 入 

记录 了 14+0 的 写 出 

32 字 节 (32 B) 已 复制 ,9.0001026 秒 , 312 kB/ 秒 


另外 一 个 hello-2.0 目 孙 ， 其 中 的 文本 文件 和 二 进 制 文件 都 有 所 更 
改 % 


$mkdir hello-2.0 

$printf "hello\nworld\n">hello-2.0/readme.txt 

$dd if=/bin/l1s of=hello-2.0/binary.dat count=1 bs=64 
记录 了 1+0 的 读 入 

忆 录 了 14+0 的 写 出 
64 字 节 (64 B) 已 复制 ,9.0001022 秒 ,626 kB/ 秒 


< 


然后 执行 git diff 命 令 。 命 令 中 的 --no-index 参 数 对 于 不 在 版 本 库 中 
的 目录 /文件 进行 比较 时 可 以 省 略 。 其 中 还 用 了 --no-prefix 参 数 ， 这 样 
就 可 以 生成 前 组 级别 (patch level) 为 1 的 补丁 文件 。 


$git diff--no-index--binary--no-prefix\ 

hello-1.0 hello-2.0>patch.txt 

$cat patch.txt 

diff--git hello-1.0/binary.dat hello-2.0/binary.dat 

index 

dc2e37f81e0fa88308bec48cd5195b6542e61a20. .bf948689934caf2d874ff8 
168cb716fbc2a 

127c3 100644 

GIT binary patch 

delta 37 

hcmY#zn4dqBGzyJX+< }pH93=9qo77QFfQiegAORUZd1MdI; 

delta 4 

LcmZ=zn4kav0O;B;E 

diff--git hello-1.0/readme.txt hello-2.0/readme.txt 

index ce01362..94954ab 100644 

---hello-1.0/readme .txt 

+++hello-2.0/readme. txt 

Q@@-1+1, 200 

hello 

+world 


进入 到 hello-1.0 目 录 ， 执 行 git apply 应 用 补丁 ， 即 使 hello-1.0 不 是 
一 个 Git 库 。 


$cd hello-1.0 
$git apply../patch.txt 


会 惊喜 地 发 现 hello-1.0 应 用 补丁 后 ， 已 经 变 得 和 hello-2.0 一 样 了 。 


$git diff--stat.../hello-2.0 


命令 git apply 也 文 持 反 回应 用 补丁 。 反 回应 用 补丁 后 ，hello-1.0 中 
的 文件 被 还 原 ， 和 hello-2.0 比 较 又 可 以 看 到 差异 了 。 


$git apply-R../patch.txt 

$git diff--stat.../hello-2.0 
{.=>../hello-2.0}/binary.dat|Bin 32->64 bytes 
{.=>../h el 1 o0-2.0}/read me,txt|1+ 

2 files changed,1 insertions(+),0 deletions(-) 


[1] http://marc.info/?l=git&m=129058163119515&w=2 


38.3 ”其 他 工具 对 Git 扩 展 补 丁 文 件 的 文 持 


Git 对 二 进 制 提供 文 持 的 扩展 的 补丁 文件 格式 ， 已 经 成 为 补丁 文件 
格式 的 新 标准 ， 被 其 他 一 些 应 用 软件 所 接受 。 例 如 MercualHg 束 提供 
了 对 Git 太 展 补丁 格 式 的 文 持 。 


为 hg diff 命 令 增加 --git 参 数 ， 实 现 Git 扩 展 diff 格 式 的 输出 。 


$hg diff--git 


Hg 的 MQ 搬 件 提供 了 对 Git 补 丁 的 文 持 。 


$cat .hg/patches/1.diff 

#HG changeset patch 

#User Jiang Xin<worldhello.net AT gmail DOT com> 

#Date 1286711219-28800 

#Node ID ba66b7bca4baec41a7d29c5cae6bea6d868e2c4b 

#Parent 0b44094c755e181446c65c16a8b602034e65efd7 

new data 

diff--git a/binary.data b/binary.data 

new file mode 100644 

index 

0000000000000000000000000000000000000000. .dc2e37f81e0fa88308bec4 
8cd5195b6542e 

61a20 

GIT binary patch 

literal 32 

bc$}+u^> JfjwMqH=CI&kOS5HCROON7&gGBE;C 


第 39 章 ” 云 存 储 


通过 云 存 储 ， 将 个 人 数据 备份 在 网 络 上 是 非常 吸引 人 的 服务 ， 比 
较 著名 的 公司 或 产品 有 Dropbox (1 、Surgarsync(*| 、Live Mesh Bl 、 
Syncplicity 所 等。 这 些 产品 的 特点 是 能 够 和 操作 系统 的 shel 整 合 ， 例 
如 和 Windows 的 资源 管理 器 或 Linux 上 的 nautilus 整 合 ， 当 本 地 数据 有 改 
动 时 会 自动 同步 到 远程 的 “ 云 存储 ”上 。 用 户 可 以 在 多 个 计算 机 或 手持 
设备 上 配置 和 同一 个 “云端 ”的 账号 同步 ， 从 而 实现 在 多 个 计算 机 或 多 
个 手持 设备 上 的 数据 同步 。 


39.1 现 有 云 存 储 的 问题 
和 遗憾 的 是 我 并 未 使 用 过 上 壕 云 存储 服务 ， 主 要 是 支持 Linux 操 作 系 


统 的 云 存储 客户 端 比较 少 ， 或 者 即使 有 也 因为 网 络 的 局 限 而 无 法 访 
问 ， 但 是 可 以 通过 相关 文档 了 解 到 其 实现 的 机 理 。 


仅 支持 对 部 分 历史 数据 的 备份 。 


Dropbox 文 持 30 天 数据 备份 ，Surgarsync 每 个 文件 仅 保留 5 个 备份 
(对 于 付费 用 户 ) ， 对 于 免费 用 户 仅 保 留 2 个 备份 。 


数据 同步 对 网 络 读 寓 的 依赖 比较 高 。 


“云端 ? 币 多 个 设备 共生 ， 神 突 解决 比较 困难 。 


Surgarsync 会 将 冲突 的 文件 目 动 保存 为 多 份 ， 造 成 磁盘 空间 超出 配 
额 。 其 他 有 的 产品 在 直到 冲突 时 集 止 同步 ， 让 用 户 决定 选择 哪个 版 


在 介绍 Git 的 书 里 介绍 云 存储 ， 是 因为 上 述 云 存储 实现 和 Git 有 关 
吗 ? 不 是 。 实 际 上 通过 上 面 各 个 云 存储 软件 特性 的 介绍 ， 有 经 验 的 
Linux 用 户 会 感觉 这 些 产 品 在 数据 同步 时 和 Linux 下 的 rsync、unison 等 


数据 同步 工具 非 党 类似， 也 许 只 是 在 服务 套 端 增加 了 历史 备份 而 已 。 


已 经 有 用 户 答 试 将 云 存 储 和 Git 结 合 使 用 ， 束 是 将 Git 库 本 吴 放 在 
本 机 的 云 存 储 同 步 区 (如 Dropbox 目 录 下 ) ，Git 库 被 同步 至 云端 。 即 
用 云 存储 作为 二 传 手 ， 实 际 上 还 是 基于 本 地 协议 操作 Git。 这 样 实际 上 


征 会 有 问题 的 。 


如 条 两 合 机 器 各 目 进行 了 提交， 云 存储 同步 一 定 会 引发 冲突 ， 这 
种 冲突 是 难以 解决 的 。 
云端 对 Git 的 每 个 文件 都 进行 备份 ， 包 括 执行 git gc 命令 打包 后 丢弃 


掉 的 松散 对 象 。 这 实际 对 于 Git 是 不 需要 的 ， 会 当 费 本 来 束 有 限 的 空间 
配额 。 


因为 版 本 库 操 作 触 发 的 git gc--auto 命 令 会 周期 性 地 整理 版 本 库 ， 
从 而 导致 即使 Git 版 本 库 的 一 个 小 提交 也 可 能 会 触发 大 量 的 云 存储 数据 
传输 。 


[1| https:/www.dropbox.com/ 
[2] https:/www.sugarsync.com/ 
[3] https:/www.mesh.com/ 


[4] http://www.syncplicity.com/ 


39.2 _Git 式 云 存储 畅想 


GitHub 是 Git 风 格 的 云 存储 ， 但 缺乏 像 之 前 所 到 的 云 存储 提供 的 傻 
瓜 式 服务 ， 只 有 Git 用 户 才 能 真正 利用 好 ， 这 大 大 限制 了 Git 在 云 存储 
领域 的 推广 。 下 面 是 我 的 一 个 预言 : 一 个 结合 了 Git 和 傻瓜 式 云 存储 的 
网 络 存 储 服务 终 将 诞生 。 新 的 傻瓜 式 云 存储 将 有 下 列 特征 : 


1. 关 异同 步 传输 


用 户 体验 最 为 天 键 的 是 网 络 传输 ， 如 采用 Git 可 以 在 同步 时 实现 仅 
对 文件 差异 进行 数据 传输 ， 会 大 大 提高 同步 效率 。 之 所 以 现 有 的 在 线 
备份 系统 实现 不 了 “差异 同步 传输 ”， 且 因为 没有 在 本 地 对 上 一 次 同步 
时 的 数据 做 备份 ， 只 能 通过 时 间 戳 或 文件 的 哈 希 值 判断 文件 是 否 改 
变 ， 而 无 法 得 出 文件 修改 前 后 的 差异 。 


可 以 很 容易 地 测试 云 存 储 软件 的 网 络 传输 性 能 。 准 备 一 个 大 的 压 
缩 包 (使 同步 时 的 压缩 传输 可 以 忽略 ) ， 测 试 一 下 同步 时 间 。 再 在 该 
文件 后 面 追加 几 个 字 季 ， 然 后 检查 同步 时 间 。 比 较 前 后 两 个 时 间 ， 融 
可 以 看 出 同步 是 否 实现 了 仅 针 对 差异 的 同步 传输 。 


2. 可 预测 的 本 地 及 云端 存储 空间 的 占用 


要 想 实 现 前 面 提 到 的 差异 同步 传输 ， 丈 必须 在 本 地 保存 上 一 次 同 
步 时 文件 的 备份 。Subversion 征 用 一 份 元 余 的 本 地 拷贝 实现 的 ， 这 样本 
地 存储 大 小 是 实际 文件 的 两 倍 。Git 在 本 地 是 完全 版 本 库 ， 占 用 空间 的 
逐渐 增加 会 变 得 不 可 预测 。 


使 用 Git 实 现 云 存储 ， 怠 要 解决 在 本 地 及 在 服务 硕 端 空间 占用 不 可 
预测 的 问题 。 对 于 服务 右 端 ， 可 以 采用 前 面 介绍 的 Gistore 软 件 重 整 版 
本 库 的 方法 ， 或 者 通过 基于 历史 和 版 本 重建 提交 然后 变 基 来 实现 提交 数 
量 的 删 减 。 对 于 客户 问 来 说 ， 只 保留 一 个 提交 束 够 了 ， 类 似 Subversion 
的 文件 的 原始 拷贝 ， 这 束 需 要 在 客户 端 基于 Git 原 理 重 新 实现 。 


3. 更 高 效 的 云端 存储 效率 


现 有 的 云 存 储 效率 不 高 ， 很 有 可 能 因为 见 余 备份 而 导致 存储 超过 
配额 ， 即 使 服务 提供 商 的 配额 计算 是 以 最 后 一 个 版 本 计算 的 ， 实 际 的 
位 盘 占 用 还 是 很 可 观 的 。 


Git 克 层 实现 了 一 个 对 内 容 跟 踩 的 文件 系统 ， 相 同 内 容 的 文件 即使 
文件 名 和 目录 不 同 ， 在 Git 看 来 都 是 一 个 对 象 并 用 一 个 文件 存储 (文件 
名 是 内 容 相关 的 SHA1 哈 希 值 ，。 因 此 Git 方 式 实现 的 云 存 储 在 空间 的 
节省 上 有 先天 的 优势 。 


4. 目 动 进行 冲突 解决 


冲突 解决 是 和 文件 同步 相关 的 ， 只 有 通过 “差异 同步 传输 ”解决 了 
同步 的 性 能 瓶 贷 ， 才 能 为 冲突 解决 打下 基础 。 先 将 冲突 的 各 个 版 本 都 
同步 到 本 地 ， 然 后 进行 目 动 冲突 解决 ， 如 采 神 突 无 法 目 动 解决 ， 再 提 
示 用 户 手工 解决 冲突 。 还 有 ， 如 采 在 手工 圳 突 解决 时 引入 类 似 kdiff3 一 
样 的 工具 ， 对 用 户 会 更 有 吸引 力 。 


5.Git 提 交 中 引入 特殊 标识 


如 果 使 用 变 基 或 其 他 技术 实现 备份 提交 数量 的 删 减 ， 束 会 在 云端 
的 提交 与 本 地 数据 的 合并 上 产生 问题 。 可 以 通过 为 提交 引入 特殊 的 唯 
一 性 标识 ， 不 随 着 Git 变 基 而 改变 ， 就 像 在 Gerrit 中 的 Change-Id 标 签 一 
样 。 


我 相信 ， 基 于 Git 的 文件 系统 及 传输 机 理 可 以 实现 一 个 更 好 用 的 去 
存储 服务 0 。 


[1] 在 本 书 基本 完稿 时 ， 听 说 了 一 个 名 为 SparkleShare 的 项 目 ， 似 乎 就 
是 一 个 基于 Git 的 云 存 储 方案 。 网 址 : http://sparkleshare.org/。 


第 8 篇 Git 杂 谈 


Git 有 着 非常 庞杂 的 命令 集 和 功能 ， 到 目前 为 止 尚 有 一 些 命令 及 要 
点 还 没有 介绍 。 在 构思 本 书 的 过 程 中 ， 我 尝试 用 FreeMind 软 件 将 准备 
讲述 的 Git 的 各 个 命令 和 要 点 在 各 个 章节 之 间 拖 动 ， 以 期 在 内 容 上 更 加 
充实 ， 组 织 上 更 加 合理 ， 讲 述 上 更 加 方便 ， 但 最 终 还 是 剩 下 了 一 些 Git 
命令 和 要 点 没有 安排 在 前 面 的 章节 中 。 于 是 这 些 不 党 用 的 Git 命 令 和 要 
点 (缺乏 它们 会 影响 一 本 被 冠 以 “权威 指南 ”的 书 的 完备 性 ) 放 在 本 书 
的 最 后 “Git 杂 谈 ” 中 予以 讲述 。 


本 篇 首先 用 一 章 的 内 容 来 介绍 跨 平台 项 目 在 使 用 Git 时 应 注意 的 事 
项 ， 包 括 字 符 集 问题 、 文 件 名 大 小 写 问 题 、 文 本 文件 换行 符 问题 。 然 
后 ， 接 下 来 的 一 草 会 概要 介绍 本 书 到 目前 为 止 尚未 涉猎 到 的 Git 话 题 和 
相关 命令 ， 如 : 属性、 钩子、 模板 、 黎 臣 检 出 、 浅 克隆 及 尹 接 ， 还 会 


介绍 git replace 和 git notes 等 命令 。 


第 40 章 ” 跨 平 台 操 作 Git 


您 是 在 什么 平台 (操作 系统 ) 中 使 用 Git 呢 ? 图 40-1 是 网 上 发 布 的 
一 个 Git 使 用 平台 调查 结果 的 截图 由 ， 从 中 可 以 看 出 排 在 前 三 位 的 是 : 
Linux、Mac OS X 和 Windows。 而 Windows 用 户 中 又 以 使 用 msysGit 的 
用 户 和 下 多” 


On which operating system(s) do you use GIt? 


40-1 _Git 用 户 操作 系统 使 用 分 布 图 


在 如 今 手持 设备 争夺 激烈 的 年 代 ， 在 什么 操作 系统 上 进行 软件 开 
发 工作 已 经 变 得 不 那么 重要 了 ， 很 多 手持 设备 都 提供 可 以 运行 在 各 种 
主流 操作 系统 上 的 虚拟 器 ， 因 此 一 个 项 目 团 队 的 成 员 根据 各 目的 使 用 
习惯 ， 可 能 使 用 不 同 的 操作 系统 。 当 一 个 团队 中 不 同 的 成 员 在 不 同 的 
平台 中 使 用 Git 进 行 交 互 时 ， 可 能 会 遇 到 平台 兼容 性 的 问题 。 


即使 团队 成 员 都 在 同一 种 操作 系统 上 工作 (如 Windows) ,但 Git 
服务 器 可 能 架设 在 另外 的 平台 上 (如 Linux) ， 或 者 产品 的 源 代码 被 分 
发 到 另外 的 平台 上 进行 编译 、 部 署 ， 同 样 痢 会 遇 到 平台 兼容 性 的 问 


题 。 


40.1 字符 集 问 题 


本 书 第 1 篇 “第 3 章 安 装 Git” 就 已 经 详细 介绍 了 不 同 平台 对 本 地 字符 
集 (如 中 文 ) 的 支持 情 况 ， 本 章 将 再 做 一 次 简单 的 概述 。 


Linux、Mac OS X 及 Windows 下 的 Cygwin 默 认 使 用 UTF-8 字 符 集 。 
Git 运 行 在 这 些 平 台 下 ， 能 够 使 用 本 地 语言 (如 中 文 ) 写 提 交 说 明 、 命 
名 文件 ， 甚 至 使 用 本 地 语言 命名 分 文 和 里 程 碑 。 在 这 些 平 台 上 唯一 要 
做 的 就 是 对 Git 进 行 如 下 设置 ， 以 便 使 用 了 本 地 语言 《如 中 文 ) 命名 文 
件 后 ， 能 够 在 状态 查看 、 差 异 比较 时 正确 地 显示 文件 名 。 


$git config--global core.quotepath false 


但 是 如 果 在 Windows 平 台 使 用 msysGit， 或 者 在 其 他 平台 使 用 非 
UTF-8 字 符 集 ， 要 想 使 用 本 地 语言 撰写 提交 说 明 、 命 名 文件 名 和 目录 
名 束 非 党 具有 挑战 性 了 。 例 如 对 于 使 用 GBK 了 字符 集 的 中 文 Windows， 
需要 为 Git 进 行 如 下 设置 ， 才 能 够 在 提交 说 明 中 正确 地 使 用 中 文 。 


$git config--system core.quotepath false 
$git config--system i1i8n.commitEncoding gbk 
$git config--system i1i8n.logOutputEncoding gbk 


当 像 上 面 那 样 设置 i18n.commitEncoding 后 ， 如 果 执 行 提 交 ， 就 会 
在 提交 对 象 中 骸 入 编码 设置 的 指令 。 例 如 在 Windows 中 使 用 msysGit 执 
行 一 次 提交 ， 在 Linux 上 使 用 git cat-file 命 令 查看 提交 时 会 出 现 乱 码 ， 需 


要 使 用 iconv 命 令 对 输出 进行 子 符 集 转换 ， 才 能 正确 查看 该 提交 对 象 。 


阿 住 富 。 


$git cat-file-p HEAD|iconv-f gbk-t utf-8 

tree 00e814cda96ac016bcacabcf4c8a84156e304ac6 

parent 52e6454db3d99c85b1b5a00ef987f8fc6d28c020 

author Jiang Xin<jiangxin@ossxp.com>1297241081+0800 

committer Jiang Xin<jiangxin@ossxp.com>1297241081+0800 encoding 
gbk 

添加 中 文 说 明 。 


因为 在 提交 对 象 中 声明 了 正确 的 字符 集 ， 因 此 在 Linux 下 可 以 用 git 
log 命 令 正 确 显 示 msysGit 生 成 的 包含 中 文 的 提交 说 明 。 


但 是 对 于 非 UTF-8 字 符 集 平台 (如 msysGit) ，Git 当 前 版 本 
(1.7.4) 对 使 用 本 地 字符 (如 中 文 ) 命名 文件 或 目录 的 支持 尚 不 完 

善 。 文 件 名 和 目录 名 实际 上 是 写 在 树 对 象 中 的 ，Git 在 创建 树 对 象 时 ， 
以 本 地 字符 集 而 非 UTF-8 字 符 集 进行 保存 ， 因 而 在 跨 平台 时 会 造成 文 
件 名 乱码 。 例 如 下 面 的 示例 显示 的 是 在 Linux 平 台 (UTF-8 字 符 集 ) 下 
查看 由 msysGit 提 交 的 包含 中 文 文件 的 树 对 象 。 注 意 要 在 git cat-file 命 令 
的 后 面 通过 管道 符号 调用 iconv 命 令 进行 字符 转换 ， 否 则 不 能 正确 地 显 
示 中 文 。 如 果 直 接 在 Linux 平 台 检 出 ， 检 出 的 文件 名 显示 为 乱码 。 


$git cat-file-p HEAD^{tree}|iconv-f gbk-t utf-8 
100644 blob 8cob112f56b3b9897007031ea38c130bgb161d5a 说 明 .txt 


[1| http:/www.survs.com/results/33Q0OZZE/MV653KSPI2 


40.2 ”文件 名 大 小 写 问题 


Linux、Solaris、BSD 及 其 他 类 Unix 操 作 系统 使 用 的 是 大 小 写 敏感 
的 文件 系统 ， 而 Windows 和 Mac OS X (默认 安装 ) 的 文件 系统 则 是 大 
小 写 不 敏感 的 文件 系统 。 即 用 文件 名 README、readme 及 Readme ( 混 
合 大 小 写 ) 进行 访问 ， 在 Linux 等 操作 系统 上 访问 的 是 不 同 的 文件 ， 而 
在 Windows 和 Mac OS XX 上 则 指向 同一 个 文件 。 换 句 话 说 ， 不 同 的 文件 
README、readme 及 Readme 在 Linux 等 操作 系统 上 可 以 共存 ， 而 在 
Windows 和 Mac OS X 上 ， 这 些 文 件 只 能 同时 存在 一 个 ， 为 外 的 会 和 被覆 
盖 ， 因 为 在 大 小 写 不 敏感 的 操作 系统 看 来 ， 这 些 文件 是 同一 个 文件 。 


如 果 在 Linuxz 上 为 Git 版 本 库 添 加 了 两 个 文件 名 仅 大 小 写 不 同 的 文 
件 〈 文 件 内 容 各 不 相同 ) ， 如 README 和 readme。 当 推送 到 服务 器 的 
共享 版 本 库 上 ， 并 在 文件 名 大 小 写 不 敏感 的 操作 系统 中 克隆 或 同步 
时 ， 就 会 出 现 问题 。 例 如 在 windows 和 Mac OS X 平 台 上 执行 git clone 
后 ， 在 本 地 工作 区 中 出 现 两 个 同名 文件 中 的 一 个 ， 而 另外 一 个 文件 会 
被 覆盖 ， 这 就 会 导致 Git 对 工作 区 中 的 文件 造成 误 判 ， 在 提交 时 会 导致 
文件 内 容 被 破坏 。 


当 一 个 项 目 存 在 跨 平 台 开 发 的 情况 时 ， 为 了 避免 这 类 问题 的 发 
生 ， 在 一 个 文件 名 大 小 写 敏感 的 操作 系统 (如 Linux) 中 克隆 版 本 库 


后 ， 应 立即 对 版 本 库 进行 如 下 设置 ， 让 版 本 库 的 行为 好 似 对 文件 名 大 
小 写 不 敏感 。 


$git config core.ignorecase true 


Windows 和 Mac OS X 在 初始 化 一 个 版 本 库 或 殉 隆 一 个 版 本 库 时 ， 
会 自动 在 版 本 库 中 包含 配置 变量 core.ignorecase 为 true 的 设置 ， 除 非 版 
本 库 不 是 通过 元 隆 而 是 直接 从 Linux 上 找 贝 而 来 的 。 


当 版 本 库 包公 了 core.ignorecase 为 true 的 配置 后 ， 文 件 名 在 文件 添 
加 时 便 被 唯一 确定 。 如 琳 之 后 修改 文件 内 容 的 同时 又 修改 了 文件 名 中 
字母 的 大 小 写 ， 只 会 被 视 为 对 文件 内 容 的 修改 ， 执 行 提交 不 会 改变 文 
件 名 。 如 采 对 添加 文件 时 设置 的 文件 名 的 大 小 写 不 满意 ， 确 实 需 要 对 
文件 重 命名 ， 对 于 Linux 来 说 很 商 单 ， 直 接 运 行 git mv 命令 显 式 地 对 文 
件 进 行 重 命名 操作 。 例 如 执行 下 面 的 命令 束 可 以 将 changelog 文 件 的 文 
件 名 修改 为 ChangeLog 。 


$git mv changelog ChangeLog 
$git commit 


但 是 对 于 Windows 和 Mac OS X 却 不 能 这 么 操作 ， 因 为 Git 会 拒绝 这 
样 的 重 命名 操作 : 


$git mv changelog ChangeLog 
fatal:destination exists,source=changelog,destination=ChangeLog 


而 需要 像 下 面 这 样 ， 苑 将 文件 重 命名 为 另外 的 一 个 名 称 ， 再 执行 
一 次 重 命名 改 回 为 正确 的 文件 名 ， 如 下 : 
$git mv changelog non-exist-filename 


$git mv non-exist-filename ChangeLog 
$git commit 


40.3 ”换行 从 问题 


每 一 个 通用 的 版 本 控制 系统 ， 无 论 是 CVS、Subversion、Git， 还 
是 其 他 ， 都 要 面 对 换 行 符 转 换 的 问题 。 这 是 因为 作为 通用 的 版 本 控制 
系统 ， 一 定 会 面 对 来 自 不 同 操作 系统 的 文件 ， 而 不 同 的 操作 系统 在 处 
理 文本 文件 时 ， 可 能 使 用 不 同 的 换行 符 。 


1. 不 同 的 操作 系统 可 能 使 用 不 同 的 换行 符 


文本 文件 的 每 一 行 结 尾 都 用 一 个 或 两 个 特殊 的 ASCII 字 符 进 行 标 
识 ， 这 个 标识 就 是 换行 符 。 主 要 的 换行 符 有 三 种 : LF (line feed 即 换 
行 ，C 语 言 等 用 \m' 表 示 ， 相 当 于 十 六 进 制 的 0x0A) 、CR (Carriage 
return 即 回 车 ，C 语 言 等 用 \r' 表 示 ， 相 当 于 十 六 进 制 的 0x0D) 和 CRLF 
( 即 由 两 个 字符 CR+LF 组 成 ， 即 "An"， 相 当 于 十 六 进 制 的 0x0D 
0x0A) ， 分 别 用 在 不 同 的 操作 系统 中 四。 


LF 换行 符 : 用 于 Multics、Unix、 类 Unix (如 GNU/Linux、AIX、 
Xenix、Mac OS X、FreeBSD 等 ) 、BeOS、Amiga、RISC OS 等 操作 系 


统 中 。 


CRLE 换 行 符 : 用 于 DEC TOPS-10、RT11 和 其 他 早期 的 非 Unix ， 


以 及 CP/M、MP/M、DOS (MS-DOS、PC-DOS 等 ) 、Atari TOS、 


OS/2、Microsoft Windows、Symbian OS、Palm OS 等 系统 


CR 换行 符 : 用 于 Commodore 8 位 机 、TRS-80、 苹 果 II 家 族 、Mac 
OS 9 及 更 早 版 本 。 实 际 上 ， 自 从 苹果 的 Mac OS 从 第 10 版 转向 Unix 内 核 
开始 ， 依 据 不 同 的 文本 文件 换行 符 ， 主 流 的 操作 系统 可 以 划分 为 两 大 
阵营 :一 个 是 微软 Windows 作 为 一 方 ， 使 用 CRLF 作 为 换行 答 ， 男 外 一 
方 包括 Unix、 类 Unix (如 Linux 和 Mac OS X 等 ) 使 用 LF 作为 换行 符 。 
分 属 不 同 阵 营 的 操作 系统 之 间 交 换文 本 文件 会 因为 换行 符 的 不 同 而 造 
成 障碍 ， 而 使 用 版 本 控制 系统 ， 也 同样 会 遇 到 换行 符 的 麻烦 : 


编辑 如 不 能 识别 换行 特 ， 可 能 会 显示 为 特殊 字符 ， 如 Linux 上 的 编 
辑 妖 显示 的 和 ^M 特 殊 字符 ， 就 是 拜 Windows 的 CRLF 换 行 特 所 赐 。 或 者 
丢弃 换行 符 ， 如 来 目 Linux 的 文本 文件 ， 在 Windows 上 打开 可 能 会 因为 
识别 不 了 换行 符 ， 导 致 所 有 的 行 合并 在 一 起 。 


版 本 库 中 的 文件 被 来 目 不 同 操作 系统 的 用 户 改 来 改 去 ， 在 某 一 次 
提交 中 换行 符 为 LFE， 在 下 一 次 提交 中 被 蔡 换 为 CRLF， 这 不 但 会 在 得 
看 文件 版 本 间 的 差异 时 造成 困惑 (所 有 的 行 都 显示 为 变更 ， 还 会 给 
版 本 库 的 存储 市 来 不 必要 的 元 余 。 


可 能 会 在 一 个 文件 中 引入 混杂 的 换行 符 ， 即 有 的 行 是 LF， 而 有 的 
行 是 CRLF。 无 论 在 哪个 操作 系统 中 用 编辑 器 打开 这 样 的 文件 ， 或 多 或 
少 都 会 感到 困惑 。 


如 采 版 本 控制 系统 提供 文本 文件 换行 符 的 目 动 转换 ， 在 Windows 
平台 将 版 本 库 文 件 寻 出 为 源码 包 并 发 布 ， 当 该 源码 包 被 Linux 用 户 下 载 
后 ， 编 译 、 运 行 可 能 会 有 问题 ， 反 之 亦 然 。 


2. 文 件 类 型 判别 ， 是 换行 符 转 换 的 基础 


几乎 所 有 的 版 本 库 控制 系统 都 采用 这 样 的 解决 方案 : 对 于 文本 文 
件 ， 在 版 本 库 中 保存 时 换行 符 使 用 LF， 当 从 版 本 库 检 出 到 工作 区 时 ， 
则 根据 平台 的 不 同 或 用 户 设置 的 不 同 ， 来 对 文本 文件 的 换行 符 进行 转 
换 (转换 为 LF、CR 或 CRLF) 。 


为 什么 换行 符 转 换 要 特意 强调 文本 文件 呢 ? 这 是 因为 如 果 对 二 进 
制 文件 (程序 或 数据 当中 出 现 的 换行 符 进 行 上 述 转换 ， 会 导致 二 进 
制 文件 被 破坏 。 因 此 判别 文件 类 型 是 文本 文件 还 古 二 进 制 文 件 ， 是 进 
行文 件 换行 符 正确 转换 的 基础 。 


有 的 版 本 控制 系统 ， 如 CVS， 必 须 在 添加 文件 时 人 为 地 设 定 文件 
类 型 (用 -kb 参数 设 定 二 进 制 文 件 ，， 一 旦 用 户 起 记 对 二 进 制 文件 进行 
标记 ， 束 会 造成 二 进 制 文件 被 破坏 。 这 种 破坏 有 时 会 藏 得 比较 深 ， 例 
如 在 Linux 上 检 出 文件 一 切 正常 ， 因 为 版 本 库 中 被 误 判 为 文本 文件 的 
形 文件 中 所 包含 的 字符 0x0A 在 Linux 上 检 出 时 没有 改变 ， 但 是 在 
Windows 上 检 出 时 会 导致 图 形 文 件 中 的 0x0A 字 符 被 转换 为 0x0D 0x0A 
两 个 字符 ， 从 而 造成 图 片 被 破坏 。 


有 的 版 本 控制 系统 可 以 自动 识别 文本 文件 和 二 进 制 文件 ， 但 是 识 
别 算法 存在 问题 。 例 如 Subversion 检 查 文件 的 前 1024 字 节 的 内 容 ， 如 果 
其 中 包含 NULL 字 符 (0x00) ， 或 者 超过 15% 的 字符 是 非 ASCII 字 符 ， 
则 Subversion 认 定 此 文件 为 二 进 制 文件 加 。 这 种 算法 会 将 包含 大 量 中 
文 的 文本 文件 当 作 二 进 制 文件 ， 不 进行 换行 符 转换 ， 也 不 进行 版 本 间 
的 比较 (除非 强制 执行 。 


Git 显 然 比 Subversion 更 了 解 这 个 世界 上 文字 的 多 样 性 ， 因 此 在 判 
别 二 进 制 文件 上 没有 多 余 的 判别 步 又 ， 只 对 blob 对 象 的 前 8000 个 字符 
进行 检查 ， 如 果 其 中 出 现 NULL 字 符 (0x00) 则 当 作 二 进 制 文件 ， 否 
则 为 文本 文件 中 。Git 还 人 允许 用 户 通过 属性 文件 对 文件 类 型 进行 设置 ， 
属性 文件 设置 优先 。 


Git 上 默认 并 不 开局 文本 文件 的 换行 符 转 换 ， 因 为 毕 况 Git 对 文件 是 
否 征 二 进 制 文件 所 做 的 猜测 存在 误 判 的 可 能 。 如 采用 户 通过 属性 文件 
或 其 他 方式 显 式 地 对 文件 类 型 进行 了 设置 ， 则 Git 束 会 对 文本 文件 开启 
换行 符 转 换 。 


下 面 是 一 个 属性 文件 的 示例 ， 为 方便 描述 标 以 行 号 。 


* ,七 Xt text 
*,VCcproj eol=crj]f 
*,Sh eol=1f 

*, jpg-text 

*, jpeg binary 


OPPODPcP 


包含 了 上 面 属性 文件 的 版 本 库 ， 会 将 以 .txt、.vcproj、.sh 为 扩展 名 
的 文件 视 为 文本 文件 ， 在 处 理 过 程 中 会 进行 换行 符 转 换 ， 而 将 
以 .jpg、.jpeg 为 扩展 名 的 文件 视 为 二 进 制 文件 ， 不 进行 换行 符 转换 。 


3. 依 据 属性 文件 进行 换行 符 转 换 


关于 属性 文件 ， 会 在 后 面 的 章节 详细 介绍 ， 现 在 可 以 将 其 理解 为 
工作 区 目录 下 的 .gitattributes 文 件 ， 其 文件 匹配 方法 及 该 文件 的 作用 范 
围 和 .gitignore 文 件 非常 类 似 。 


像 上 面 的 属性 文件 示例 中 ， 第 1 行 设 置 了 扩展 名 为 .txt 的 文件 具有 
text 属 性 ， 则 所 有 扩展 名 为 .txt 的 文件 添加 到 版 本 库 时 ， 在 版 本 库 中 创 
建 的 blob 文 件 的 换行 符 一 律 被 转换 为 LF。 而 当 扩 展 名 为 .txt 的 文件 检 出 
到 工作 区 时 ， 则 根据 平台 的 不 同 而 使 用 不 同 的 换行 符 ， 如 在 Linux 上 检 
出 则 使 用 LF 换行 符 ， 如 在 Windows 上 检 出 则 使 用 CRLF 换 行 符 。 


示例 中 的 第 2 行 设置 扩展 名 为 .vcproj 的 文件 的 属性 eol 的 值 为 crlf， 
隐 含 厦 该 文件 属于 文本 文件 的 合 义 ， 当 同 版 本 库 添 加 扩展 名 为 .vcproj 
的 文件 时 ， 在 版 本 库 中 创建 的 blob 文 件 的 换行 符 一 律 转 换 为 LF。 而 当 
该 类 型 的 文件 检 出 到 工作 区 时 ， 则 一 律 使 用 CRLF 作 为 换行 符 ， 不 管 十 
在 Windows 上 检 出 ， 还 是 在 Linux 上 检 出 。 


同 理 示例 中 的 第 3 行 设置 的 扩展 名 为 .sh 的 文件 也 会 进行 类 似 的 换 
行 符 转换 ， 区 别 在 于 该 类 型 文件 无 论 在 哪个 平台 检 出 ， 都 使 用 LF 作 为 


换行 符 。 


像 上 面 那 样 逐一 为 不 同类 型 的 文件 设置 换行 符 格 式 显 得 很 麻烦 ， 
可 以 在 属性 文件 中 添加 下 面 的 设置 ， 为 所 有 文件 开局 文件 类 型 自动 判 


* text=auto 


当 为 所 有 文件 设置 了 text=auto 的 属性 后 ，Git 就 会 在 文件 检 入 和 检 
出 时 对 文件 是 否 是 二 进 制 进行 判断 ， 采 用 前 面 提 到 的 方法 : 如 果 文 件 
头 部 的 8000 个 字符 中 出 现 NULL 字 符 则 为 二 进 制 文件 ， 和 否则 为 文本 文 
件 。 如 果 判 断 文 件 是 文本 文件 就 会 启用 换行 符 转 换 。 至 于 本 地 检 出 文 
件 采用 什么 换行 符 格式 ， 实 际 上 是 由 core.eol 配 置 变量 进行 设置 的 ， 不 
过 因为 core.eol 未 被 设置 时 会 采用 默认 值 native， 才 使 得 工作 区 文本 文 
件 的 检 出 采用 操作 系统 默认 的 换行 符 格 式 。 配 置 变量 core.eol 除 了 默认 
的 native 外 ， 还 可 以 使 用 {f 和 crlf， 不 过 一 般 较 少 用 到 。 


4. 使 用 Git 配 置 变量 控制 换行 符 转 换 


在 Git 1.7.4 之 前 ， 用 属性 文件 的 方式 来 设置 文件 的 换行 符 转 换 ， 只 
能 逐一 为 版 本 库 进 行 设置 ， 如 果 要 为 本 地 所 有 的 版 本 库 设 定 文 件 换行 
符 转 换 融 非 常 麻 烦 。Git 1.7.4 提 供 了 全 局 可 用 的 属性 文件 ， 实 现 了 对 换 
行 符 转 换 设 定 的 全 局 控制 ， 我 们 会 在 后 面 的 章节 予以 介绍 。 现 在 介绍 


core.autocrlf 来 开局 文本 文件 换行 符 转 


另外 一 个 方法 ， 即 通过 配置 变量 
命令 ， 对 配置 变量 core.autocrlf 进 行 设置 : 


换 的 功能 。 例 如 执行 下 面 的 


$ git config--global core.autocrlf true 


默认 Git 不 对 配置 变量 core.autocrlf 进 行 设置 ， 同 时 如 果 没 有 通过 属 
性 文件 指定 文件 的 类 型 ，Git 不 对 文件 进行 换行 符 转 换 。 但 是 将 配置 变 
量 core.autocrlf 设 置 为 下 列 值 时 ， 会 开局 Git 对 文件 类 型 的 智能 判别 并 对 
文本 文件 执行 换行 符 转 换 。 


设置 配置 变量 core.autocrlf 为 true。 


效果 束 相 当 于 为 版 本 库 中 的 所 有 文件 设置 了 text=auto 的 属性 。 即 
通过 Git 对 文件 类 型 的 目 动 判定 ， 对 文本 文件 进行 换行 符 转 换 。 在 版 本 
库 的 blob 文 件 中 使 用 LF 作为 换行 符 ， 而 检 出 到 工作 区 时 无 论 古 什么 操 
作 系 统 都 使 用 CRLF 为 换行 符 。 注 意 当 设置 了 core.autocrlf 为 tue 时 ， 会 
忽略 core.eol 的 设置 ， 工 作 区 文件 始终 使 用 CRLEF 作 为 换行 符 ， 这 对 于 
Windows 下 的 Git 非 常 适合 ， 但 不 适用 于 Linux 等 操作 系统 。 


设置 配置 变量 core.autocrlf 为 input。 


同样 开局 文本 文件 的 换行 符 转 换 ， 但 只 是 在 文件 提交 到 版 本 库 
时 ， 将 新 增 入 库 的 blob 文 件 的 换行 符 转 换 为 LF。 如 果 将 文件 从 版 本 库 
全 出 到 工作 区 ， 则 不 进行 文件 转换 ， 即 版 本 库 中 的 文件 大 是 采用 LF 换 


行 符 ， 检 出 仍旧 是 LF 作 为 换行 符 。 这 个 设置 对 Linux 等 操作 系统 下 的 
Git 非 常 适合 ， 但 不 适合 于 Windows。 


5. 换 行 符 转 换 的 异常 捕获 


无 论 用 户 征 通过 属性 文件 来 设 定 文件 的 类 型 ， 还 是 通过 Git 智 能 判 
别 ， 都 可 能 错误 地 将 二 进 制 文件 识别 为 文本 文件 ， 在 转换 过 程 中 造成 
文件 的 破坏 。 有 一 种 情况 下 的 破坏 最 为 严重 ， 吏 是 误 判 的 文件 中 包 合 
不 一 致 的 换行 符 〈 既 有 CRLF， 又 有 LF) ， 这 将 会 导致 保存 到 版 本 库 
中 的 blob 对 和 象 无 论 通过 何 种 转换 方式 都 不 能 还 原 回 原 有 的 文件 。 


Git 提 供 了 名 为 core.safecrlf 的 配置 变量 ， 可 以 用 于 捕获 这 种 不 可 逆 
的 换行 符 转 换 ， 以 提醒 用 户 注意 。 将 配置 变量 core.safecrlf 设 置 为 tue 
时 ， 如 采 发 现存 在 不 可 逆 换 行 符 转换 ， 会 报错 退出 ， 拒 绝 执 行 不 可 逆 
的 换行 符 转换 。 如 果 将 配置 变量 core.safecrlf 设 置 为 warn 则 允许 不 可 逆 
的 转换 ， 但 发 现 不 可 逆转 换 时 会 发 出 警告 。 


[1| http://en.wikipedia.org/wiki/Newline 
[2] 参 见 Subversion 源 代 码 subversiomrlibsvn_subvio.c 中 的 
svn_io_detect_mimetype2 琴 数 。 


[3] 参见 Git 源 代码 xdiff-interface.c 中 的 buffer_is_binary 范 数 。 


第 41 章 ”Git 的 其 他 特性 


41.1 属性 


Git 通 过 属性 文件 为 版 本 库 中 的 文件 或 目 孙 添加 属性 。 设 置 了 属性 
的 文件 或 目录 ， 在 执行 Git 相 关 操 作 时 会 做 特殊 处 理 ， 正 如 之 前 介绍 换 
行 符 转 换 时 设置 了 文本 属性 (text) 的 文件 那样 。 


41.1.1 属性 定义 


属性 文件 是 一 个 普通 的 文本 文件 ， 每 一 行 对 一 个 路 径 〈 可 使 用 通 
配 符 ) 设置 相应 的 属性 。 语 法 格式 如 下 : 


<pattern> <attr1i><attr2>... 


其 中 路 径 由 可 以 使 用 通配符 的 <pattern > 来 定义 ， 在 <pattern > 
后 面 可 以 设置 一 个 或 多 个 属性 ， 不 同 的 属性 之 间 用 空格 分 开 。 路 径 中 
通配符 的 用 法 和 文件 忽略 (.gitignore) 的 语法 格式 相同 ， 参 见 本 书 第 2 
篇 第 10 章 的 “10.8 文 件 和 忽略” 的 相关 内 容 。 下 面 以 text 属 性 为 例 来 介绍 属 
性 的 不 同 写法 : 


text 


直接 通过 属性 名 进行 设置 ， 相 当 于 将 text 的 属性 值 设 置 为 rue。 


对 于 设置 了 text 属 性 的 文件 ， 不 再 需要 Git 来 猜测 文件 的 类 型 ， 而 
可 以 直接 判定 为 文本 文件 并 进行 相应 的 换行 符 转 换 。 


-text 


在 属性 名 前 用 减 号 标识 ， 相 当 于 将 text 的 属性 值 设置 为 false 。 


对 于 设置 了 取 反 text 属 性 的 文件 ， 直 接 判 定 为 二 进 制 文件 ， 在 文件 
念 入 和 检 出 时 不 进行 换行 符 转换 。 


I!text 


在 属性 名 前 面 添加 感叹 号 ， 相 当 于 没有 设置 该 属性 ， 既 不 等 于 
true， 也 不 等 于 false。 对 于 未 定义 text 属 性 的 文件 ， 根 据 Git 是 否 配置 了 
core.autocrlf 配 置 变 量 来 决定 是 否 进行 换行 符 转 换 。 因 此 对 于 !text ( 没 
有 定义 text 属 性 ) 和 -text (text 属 性 设置 取 反 ) ， 两 者 存在 差异 。 


text=auto 


属性 除了 上 述 true、false 和 未 设置 三 个 状态 外 ， 还 可 以 对 属性 用 相 
关 的 枚 举 值 〈 预 定义 的 字符 串 ) 进行 设置 。 不 同 的 属性 值 可 能 有 不 同 
的 枚 举 值 ， 对 于 text 属 性 可 以 设置 为 auto。 


对 于 text 属 性 设置 为 auto 的 文件 ， 文 件 类 型 实际 上 尚未 确定 ， 需 要 
Git 读 取 文 件 内 容 进 行 智能 判别 ， 判 别 为 文本 文件 则 进行 换行 符 转 换 。 
显然 当 设置 text 属 性 为 auto 时 ， 并 不 等 同 于 设置 为 tue。 


41.1.2 属性 文件 及 优先 级 


属性 文件 可 以 以 .gitattributes 文 件 名 你 存在 工作 区 目录 中 ， 提 交 到 
版 本 库 后 就 可 以 和 其 他 用 户 共 至 项 目 文件 的 属性 设置 。 属 性 文件 也 可 
以 保存 在 工作 区 之 外 ， 例 如 保存 在 文件 .giVinfo/attributes 中 ， 则 仅 对 本 
版 本 库 生 效 ， 若 保存 在 /etc/gitattributes 上 文件 中 则 对 全 局 生效 。 在 查 
询 某 个 工作 区 某 一 文件 的 属性 时 ， 不 同位 置 的 属性 文件 具有 不 同 的 优 
先 级 ，Git 依 据 下 列 顺序 依次 访问 属性 文件 : 


(1) 文件 .git/info/attributes 具 有 最 高 的 优先 级 。 


(2) 接 下 来 检查 工作 区 同一 目录 下 的 .gitattributes， 并 依次 同上 递 
归 查 找 .gitattributes 文 件 ， 直 到 工作 区 的 根 目录 。 


(3) 然后 查询 由 Git 的 配置 变量 core.attributesfile 指 定 的 全 局 属性 
文件 。 


(4) 最 后 是 系统 属性 文件 ， 即 文件 $ (prefix) /etc/gitattributes 。 
不 同 的 Git 安 装 方式 下 这 个 文件 的 位 置 可 能 不 同 ， 但 是 该 文件 始终 和 
Git 的 系统 配置 文件 (可 以 通过 git config--system-e 命 令 打开 系统 配置 文 
件 从 而 知道 其 位 置 ) 位 于 同一 目录 中 。 


注意 : 只 有 在 1.7.4 或 更 新 版 本 的 Git 中 才 提 供 后 两 种 (全 局 的 和 系 
统 级 的 ) 属性 文件 。 可 以 通过 下 面 的 例子 来 理解 属性 文件 的 优先 级 和 
属性 设置 方法 。 


目 完 来 看 看 某 个 版 本 库 及 系统 中 所 包含 的 属性 文件 : 
其 一 是 位 于 版 本 库 中 的 文件 .gitinfo/attributes， 内 容 如 下 : 


a* foo !bar -baz 


其 二 是 位 于 工作 区 子 目 录 t 下 的 属性 文件 ， 即 t.gitattributes， 内 容 
wl 
ab*merge=filfre 


abc-foo-bar 
*,c frotz 


再 一 个 束 古 位 于 工作 区 根 目 录 下 的 属性 文件 .gitattributes， 内 容 如 
下 


abc foo bar baz 


如 果 系 统 文件 /etc/gitconfig 中 包含 如 下 配置 ， 则 每 个 用 户主 目录 下 
的 .gitattributes 文 件 都 被 作为 全 局 属性 文件 。 


[core] 
attributesfile=~/.gitattributes 


位 于 用 户主 目录 下 的 属性 文件 ， 即 文件 ~/.gitattributes 的 内 容 如 
下 : 


*text=auto 


当 碍 询 工 作 区 文件 Wabc 的 属性 时 ， 根 据 属性 文件 的 优先 级 ， 按 照 
下 列 顺序 进行 检索 : 


(1) 先 检查 属性 文件 .git/info/attributes。 显 然 该 文件 中 唯一 的 一 
行 就 和 文件 Wabc 匹 配 ， 因 此 文件 Wabc 的 属性 如 下 : 
foo:true 


bar :未 设置 


baz:false 


(2) 再 检查 和 文件 Wabc 同 目录 的 属性 文件 .gitattributes。 该 属性 
文件 的 前 两 行 和 路 径 Vvabc 相 匹配 ， 但 是 因为 属性 文件 .giVinfo/attributes 

经 提供 了 foo 和 bar 的 属性 ， 因 此 第 二 行 对 foo 和 bar 属 性 的 设置 不 起 作 
用 。 经 过 这 一 步 ， 文 件 Vabc 获 得 的 属性 为 : 


foo :true 
bar :未 设置 
baz :false 

merge:filfre 


(3) 然后 沿 工 作 区 的 当前 目录 向 上 遍历 属性 文件 ， 找 到 工作 区 根 
目录 下 的 属性 文件 .gitattributes 进 行 检 查 。 因 为 前 面 的 属性 文件 已 经 提 


供 了 foo、bar 和 baz 属 性 设置 ， 所 以 文件 Wabc 的 属性 和 上 面 第 2 步 的 结 
一 样 o 


(4) 因为 将 core.attributesfile 设 置 为 ~/.gitattributes 文 件 ， 因 此 接 
下 来 查找 用 户主 目录 下 的 文件 即 .gitattributes。 该 文件 唯一 的 一 行 匹配 
所 有 的 文件 ， 因 此 wabc 又 被 附加 了 新 的 属性 值 text=auto。 最 终 ， 文 件 
t/abc 的 属性 如 下 : 
foo:true 
bar :未 设置 
baz:false 


merge:filfre 
text:auto 


Git 提 供 了 一 个 查看 文件 属性 设置 的 命令 ，git check-attr。 针 对 本 
例 用 下 面 的 命令 可 以 查看 到 文件 Wabc 各 个 属性 的 设置 情况 。 


$git check-attr foo bar baz merge text--t/abc 
t/abc:foo:set 

t/abc:bar:unspecified 

t/abc:baz:unset 

t/abc:merge:filfre 

t/abc:text:auto 


[1] 随 着 Git 安 闭 方 式 的 不 同 ， 这 个 文件 的 位 置 也 可 能 不 同 。 


41.1.3 ”常用 属性 介绍 


1.text 


属性 text 用 于 显 式 地 指定 文件 的 类 型 ， 二 进 制 (-text) 、 文 本 文件 
(text) 或 是 开局 文件 类 型 的 智能 判别 (text=auto) 。 对 于 文本 文件 ， 
Git 会 对 其 进行 换行 符 转换 。 本 篇 第 40 章 “40.3 换 行 符 问 题 ?" 中 已 经 详细 
介绍 了 属性 text 的 用 法 ， 并 且 在 本 章 “41.1.1 属 性 定义 ”的 示例 中 对 属性 
text 的 取 值 做 了 总 结 ， 在 此 不 再 交 述 。 


在 “40.3 换 行 符 问题 ”一 他 中， 我 们 还 知道 可 以 通过 在 Git 配 置 文件 
中 设置 core.autocrlf 配 置 变量 ， 来 开局 Git 对 文件 类 型 的 智能 判别 ， 并 对 
文本 文件 开启 换行 符 转 换 。 那 么 Git 的 配置 变量 core.autocrlf 和 属性 text 
有 什么 异同 呢 ? 


将 Git 的 配置 变量 core.autocrlf 设 置 为 true 或 input， 相 当 于 设置 了 属 
性 text=auto。 但 是 Git 配 置 文件 中 的 配置 变量 只 能 在 本 地 进行 设置 并 且 
只 对 本 地 版 本 库 有 效 ， 不 能 通过 共享 版 本 库 传 递 到 其 他 用 户 的 本 地 版 
本 库 中 ， 因 而 core.autocrlf 开 启 的 换行 符 转 换 不 能 跟 其 他 用 户 共享 ， 或 
者 说 不 能 将 换行 符 转 换 策 略 设 置 为 整个 项 目 (版 本 库 ) 的 强制 规范 。 
属性 文件 则 不 同 ， 可 以 被 检 入 到 版 本 库 中 并 通过 共享 版 本 库 传 递 给 其 
他 用 户 ， 因 此 可 以 通过 在 检 入 的 .gitattributes 文 件 中 设置 text 属 性 ， 或 者 


干脆 设置 text=auto 属 性 ， 强 制 同 一 项 目的 所 有 用 户 在 提交 文本 文件 时 
都 要 规范 换行 符 。 


建议 所 有 可 能 要 进行 跨 平 台 开发 的 项 目 都 在 项 目 根 目 了 永 中 检 入 一 
个 .gitattributes 文 件 ， 根 据 文件 扩展 名 设置 文件 的 text 必 性， 或 者 设置 即 
将 介绍 的 eol 属性 。 


2.e0] 


属性 eol 用 于 设 定 文本 文件 的 换行 符 格 式 。 对 于 设置 了 eol 属性 的 文 
件 ， 如 果 没 有 设 定 text 属 性 时 ， 默 认 会 设置 text 属 性 为 tue。 属 性 eol 的 
取 值 如 下 : 


eol=crlf 


当 文件 检 入 版 本 库 时 ，blob 对 象 使 用 LEF 作 为 换行 符 。 当 检 出 到 工 
作 区 时 ， 使 用 CRLF 作 为 换行 符 。 


eol=lf 


当 文件 检 入 版 本 库 时 ，blob 对 象 使 用 LF 作为 换行 符 ， 检 出 的 时 候 
工作 区 的 文件 也 使 用 LF 作为 换行 符 。 


除了 通过 属性 设 定 换 行 从 格式 外 ， 还 可 以 在 Git 的 配置 文件 中 通过 
core.eol 配 置 变 量 来 设 定 。 两 者 的 区 别 在 于 配置 文件 中 的 core.eol 配 置 变 


量 设 置 的 换行 符 是 一 个 默认 值 ， 没 有 通过 eol 属性 指定 换行 符 格 式 的 文 
本 文件 会 采用 core.eol 的 设置 。 变 量 core.eol 的 值 可 以 设 定 为 站 、crlf 和 
native。 默 认 core.eol 的 取 值 为 native， 即 采用 操作 系统 标准 的 换行 符 格 
式 o 


下 面 的 示例 通过 属性 文件 设置 文件 的 换行 符 格 式 。 


* ,vcproj eol=crif 

*.Sh eol=1f 

扩展 名 为 .vcproj 的 文件 使 用 CRLF 作 为 换行 符 ， 而 扩展 名 为 .sh 的 文 
件 则 使 用 LF 作为 换行 符 。 在 版 本 库 中 检 入 类 似 的 属性 文件 ， 会 使 得 Git 
客户 端 无 论 在 什么 操作 系统 中 都 能 够 在 工作 区 检 出 一 致 的 换行 符 格 
式 ， 这 样 无 论 是 在 Windows 上 还 是 在 Linux 上 使 用 git archive 命 令 将 工作 
区 文件 打包 ， 导 出 的 文件 都 会 保持 正确 的 换行 符 格 式 。 


3.ident 


属性 ident 开 局 文本 文件 中 的 关键 字 扩 展 ， 即 关键 子 $1d$ 的 目 动 扩 
展 。 当 检 出 到 工作 区 时 ，$Id$ 目 动 扩展 为 $1d:， 后 面 紧 接着 40 位 SHA1 
哈 硕 值 (相应 blob 对 象 的 哈 希 值 ) ， 然 后 以 一 个 $ 字 符 结 尾 。 当 文件 检 
入 时 ， 要 把 内 容 中 出 现 的 以 $Id: 开 始 ， 以 $ 结 束 的 内 容 蔡 换 为 $Id$ 再 保 
存 到 blob 对 象 中 。 


这 个 功能 可 以 说 是 对 CVS 相 应 功能 的 致敬 。 目 动 扩展 的 内 容 使 用 
的 是 blob 的 哈 布 值 而 非 提 交 本 喘 的 哈 希 值 ， 因 此 并 无 太 大 的 实际 意 
义 ， 不 建议 使 用 。 如 果 硕 望 在 文本 文件 中 扩展 出 提交 者 姓名 、 提 区 ID 
等 更 有 实际 意义 的 内 容 ， 可 以 参照 后 面 介 绍 的 属性 export-subst 。 


4.filter 


属性 fiter 为 文件 设置 一 个 目 定 义 转换 过 滤 右 ， 以 便 文件 在 检 入 版 
本 库 及 检 出 到 工作 区 时 进行 相应 的 转换 。 定 义 转换 过 滤 如 通过 Git 配 置 
文件 来 完成 ， 因 此 这 个 属性 应 该 只 在 本 地 进行 设置 ， 而 不 要 也 不 能 通 
过 检 入 到 版 本 库 中 的 .gitattributes 文 件 来 传递 。 


例如 下 面 的 属性 文件 设置 了 所 有 的 C 语 言 源 文件 在 检 入 和 检 出 的 
时 候 使 用 名 为 indent 的 代码 格式 化 过 滤器 。 


*.c filter=indent 


然后 还 要 通过 Git 配 置 文 件 设 定 indent 过 滤 右 ， 示 例如 下 : 


[filter "indent"] 
clean=indent 
smudge=cat 


定义 过 滤器 只 要 设置 两 条 命 仿 ， 一 条 是 名 为 clean 的 配置 设 定 的 的 


命令 ， 用 于 在 文件 检 入 时 执行 ， 另 外 一 条 是 名 为 smudge 的 配置 设 定 的 


命令 ， 用 于 将 文件 检 出 到 工作 区 。 对 于 本 例 ， 在 代码 检 入 时 执行 indent 
命令 对 代码 格式 化 后 ， 再 保存 到 版 本 库 中 。 当 检 出 到 工作 区 时 ， 执 行 
cat 命 令 实际 上 相当 于 直接 将 blob 对 象 复制 到 工作 区 。 


5.diff 


和 前 面 介绍 的 属性 不 同 ， 属 性 diff 不 会 对 文件 检 入 检 出 造成 影响 ， 
而 只 是 在 查看 文件 历史 变更 时 起 作用 。 属 性 diff 可 以 取 值 如 下 : 


diff 


进行 版 本 间 的 差异 比较 时 ， 以 文本 方式 进行 比较 ， 即 使 文件 看 起 
来 像 是 二 进 制 文件 (包含 NULL 字 符 ) ， 或 者 被 设置 为 二 进 制 文件 (- 


text) 。 
-diff 


不 以 文本 方式 进行 差异 比较 ， 而 以 二 进 制 方式 进行 比较 。 默 认 二 
进 制 文件 不 进行 差异 比较 ， 因 此 包 售 -di 人 ff 属性 设置 的 文件 在 差异 比较 
时 不 显示 内 容 上 的 差异 。 对 于 有 些 文本 文件 〈 如 postscript 文 件 ) 进行 
凌 异 比较 没有 意义 ， 可 以 对 其 设置 -diff 属 性 ， 避 人 免 在 显示 提交 版 本 间 
的 差异 时 造成 干扰 。 


ldiff 


不 设置 diff 必 性， 相当 于 在 执行 莽 异 比较 时 要 对 文件 内 容 进 行 智 能 
判别 ， 如 末 文 件 看 起 来 像 古 文本 文件 ， 则 显示 文本 格式 的 差异 比较 。 


diff= < driver > 


设 定 一 个 外 部 的 驱动 用 于 文件 的 差异 比较 。 例 如 对 于 Word 文 档 的 
差异 比较 就 可 以 通过 这 种 方式 进行 配置 。 


Word 文 档 属 于 二 进 制 文件 ， 默 认 不 显示 差异 比较 。 在 Linux 上 有 
一 个 名 为 antiword 的 应 用 软件 可 以 将 Word 文 档 转换 为 文本 文件 显示 ， 
借助 该 软件 就 可 以 实现 在 Linux (包括 Mac OS X) 上 显示 Word 文 件 版 
本 间 的 差异 。 


下 面 的 Git 配 置 就 定义 了 一 个 名 为 antiword 的 适用 于 Word 有 差异 比较 
的 驱动 : 


[diff "antiword"] 
textconv=antiword 


其 中 textconv 属 性 用 于 设 定 一 个 文件 转换 命令 行 ， 这 里 设置 为 
antiword， 用 于 将 Word 文 档 转换 为 纯 文 本 。 


然后 还 需要 设置 属性 ， 修 改版 本 库 下 的 .giUinfo/attributes 文 件 就 可 
以 了 ， 痢 增 的 属性 设置 如 下 : 


*x.doc diff=antiword 


关于 更 多 的 差异 比较 的 外 部 驱动 的 设置 ， 可 以 执行 git help--web 
attributes 来 参见 相关 的 帮助 。 


6.merge 


属性 merge 用 于 为 文件 设置 指定 的 合并 策略 ， 受 影响 的 Git 命 令 
有 : git merge、git revert 和 git cherry-pick 等 。 属 性 merge 可 以 取 值 如 


merge 
使 用 内 置 的 三 向 合并 策略 。 
-merge 


将 当前 分 支 的 文件 版 本 设置 为 暂时 的 合并 结果 ， 并 且 声 明 合并 发 
生 了 冲突 ， 这 实际 上 是 二 进 制 文件 稚 认 的 合并 方式 。 可 以 对 文本 文件 
设置 该 属性 ， 使 得 在 合并 时 的 行为 类 似 于 二 进 制 文件 。 


Imerge 


和 定义 了 merge 属 性 的 效果 类 似 ， 使 用 内 置 的 三 回合 并 策略 。 然 而 
当 通 过 Git 配 置 文件 的 merge.default 配 置 变量 设置 了 合并 策略 后 ， 如 果 
没有 为 文件 设置 merge 属 性 ， 则 使 用 merge.default 设 定 的 策略 。 


merge= < driver > 


使 用 指定 的 合并 驱动 执行 三 同文 件 合并 。 驱 动 可 以 是 内 置 的 三 个 
驱动 ， 也 可 以 是 用 户 通 过 Git 配 置 文 件 自 定义 的 驱动 。 


下 面 重点 说 一 说 通过 枚 举 值 来 指定 在 合并 时 使 用 的 内 置 驱动 和 目 
定义 驱动 。 先 来 看 看 Git 提 供 的 三 个 内 置 驱动 : 


merge=text 


默认 文本 文件 在 进行 三 同 合并 时 使 用 的 驱动 。 会 在 合并 后 的 文本 


标记 神 突 的 内 容 。 


merge=binary 


默认 二 进 制 文件 在 进行 三 向 合并 时 使 用 的 驱动 。 会 在 工作 区 中 保 
持 当 前 分 文中 的 版 本 不 变 ， 但 是 会 通过 在 三 个 暂 存 区 中 进行 冲突 标 
识 ， 使 得 文件 处 于 冲突 状态 。 


merge=union 


在 文本 文件 进行 三 向 合并 的 过 程 中 ， 不 使 用 冲突 标识 符 来 标记 冲 
突 ， 而 是 将 冲突 双方 的 内 容 人 简单 地 罗列 在 文件 中 。 用 户 应 该 对 合并 后 
的 文件 进行 检查 。 请 慎 用 此 合并 驱动 。 


用 户 还 可 以 目 定 义 驱 动 。 例 如 Topgit 束 使 用 自 定 义 合并 驱动 的 方 
式 来 控制 两 个 Topgit 管 理 文 件 .topmsg 和 .topdeps 的 合并 行为 。 


Topgit 会 在 版 本 库 的 配置 文件 .giUyinfo/config 中 添加 下 面 的 设置 来 
定义 一 个 名 为 ours 的 合并 张 动 。 注 意 不 要 将 此 ours 张 动 和 本 书 第 3 篇 第 
16 草 “16.6 合 并 党 略 ” 一 玫 中 介绍 的 ours 合 并 策略 弄 混 消 。 

[merge "ours"] 


name=\ "always keep ours\" merge driver 
driver=touch%A 


定义 的 合并 驱动 的 名 称 由 merge.*.name 给 出 ， 合 并 时 执行 的 命令 
则 由 配置 merge.*.driver 给 出 。 本 例 中 使 用 了 命令 touch%A， 含 义 为 对 
当前 分 支 中 的 文件 进行 简单 的 触 磁 〈 更 新 文件 时 间 戳 ) ， 亦 即 合并 冲 
突 时 采用 本 地 版 本 ， 丢 弃 其 他 版 本 。 


Topgit 还 会 在 版 本 库 .git/info/attributes 属 性 文件 中 包含 下 面 的 属性 
设置 : 

.topmsg merge=ours 

.topdeps merge=ours 

上 未 设置 的 合 义 为 在 遇 到 合并 冲突 时 ， 对 这 两 个 Topgit 管 理 文件 
采用 在 Git 配 置 文件 中 设 定 的 ours 合 并 驱动 。Topgit 之 所 以 要 这 么 实现 
是 因为 不 同 特性 分 文 的 管理 文件 之 间 并 无 关联 ， 也 不 需要 合并 ， 在 过 


到 冲突 时 只 使 用 目 己 的 版 本 即 可 。 这 对 于 要 经 少 执 行 变 基 和 分 文 合并 
的 Topgit 来 说 ， 设 置 这 个 策略 可 以 人 簿 化 管理 ， 但 是 这 个 合并 设置 在 特 

定 情 况 下 也 存在 不 合理 之 处 。 例 如 两 个 用 户 工作 在 同一 分 文 上 ， 同 时 
更 改 了 .topmsg 文 件 以 修改 特性 分 文 的 描述 ， 在 合并 时 会 覆 次 对 方 的 修 
改 ， 这 显然 是 不 好 的 行为 。 但 是 权 衡 利 弊 ， 还 是 如 此 实现 最 好 。 


7.whitespace 


Git 可 以 对 文本 文件 中 空 日 字符 的 使 用 是 否 规范 做 出 检查 ， 在 进行 
文件 差异 比较 时 ， 将 使 用 不 当 的 空白 字符 用 红色 进行 标记 (开启 
color.diff.whitespace 1 ) 。 也 可 以 在 执行 git apply 时 通过 参数 -- 
whitespace=error 防 止 错误 的 空白 字符 应 用 到 提交 中 。 


Git 默 认 开 局 对 下 面 三 类 错误 空 犁 字符 的 检查 。 
blank-at-eol 

在 行 尾 出 现 的 空白 字符 (换行 符 之 前 ， 被 视 为 误 用 。 
space-before-tab 

在 行 首 缩 进 中 出 现在 TAB 字符 前 面 的 空白 字符 视 为 误 用 。 


blank-at-eof 


在 文件 末尾 的 空白 行 视 为 误 用 。 


Git 还 文 持 对 更 多 空 日 字符 的 误 用 做 出 检测 ， 包 括 : 


indent-with-non-tab 


用 8 个 或 更 多 的 空格 进行 缩 进 视 为 误 用 。 


tab-in-indent 


在 行 首 的 缩 进 中 使 用 TAB 字符 视 为 误 用 。 显 然 这 个 设置 和 上 面 的 


indent-with-non-tab 互 斥 。 


trailing-space 


相当 于 同时 启用 blank-at-eol 和 blank-at-eof 。 


cr-at-eol 


将 行 尾 的 CR ( 回 车 ) 字符 视 为 换行 符 的 一 部 分 。 也 就 是 说 ， 在 行 


尾 前 出 现 的 CR 字符 不 会 引起 trailing-space 报 错 。 
tabwidth=< n> 
设置 一 个 TAB 字符 相当 于 几 个 空格 ， 默 认为 8 个 。 


可 以 通过 Git 配 置 文件 中 的 core.whitespace 配 置 变 量 ， 设 置 开 司 更 
多 的 空 日 字符 检查 ， 将 要 开启 的 空 日 字符 检查 项 用 逗号 分 开 即 可 。 


如 果 和 希望 对 特定 路 径 进 行 空 日 字符 检查 ， 则 可 以 通过 属性 
whitespace 进 行 设置 。 属 性 whitespace 可 以 有 如 下 设置 : 


whitespace 


开局 所 有 的 空 日 字符 误 用 检查 。 

-whitespace 

不 对 空 日 字符 进行 误 用 检查 。 

!whitespace 

使 用 core.whitespace 配 置 变 量 的 设置 进行 空白 字符 误 用 检查 。 
whitespace=...... 

和 core.whitespace 的 语法 一 样 ， 用 过 号 分 阳 各 个 空白 字符 检查 项 。 
8.export-ignore 

设置 了 该 属性 的 文件 和 日 录 在 执行 git archive 时 不 予 导 出 。 
9.export-subst 


如 果 为 文件 设置 了 属性 export-subst， 则 在 使 用 git archive 导 出 项 目 
文件 时 ， 会 展开 相应 文件 内 容 中 的 占 位 符 ， 人 然后 再 添加 到 归档 中 。 注 


意 如 果 在 使 用 git archive 导 出 时 使 用 树 ID， 而 没有 使 用 提交 或 里 程 碑 ， 
则 不 会 展开 占 位 从 。 


占 位 符 的 格式 为 $Format:PLACEHOLDERS$， 其 中 
PLACEHOLDERS 使 用 git log--pretty=format: 相 同 的 参数 (具体 请 参见 
git help log 显 示 的 帮助 页 面 ) 。 例 如 : $Format:%H$ 将 展开 为 提交 的 哈 
希 值 ，$Format:%an$ 将 展开 为 提交 者 姓名 。 


10.delta 


如 果 设 置 属性 delta 为 false， 则 不 对 该 路 人 径 指 向 的 blob 文 件 执行 
Delta 压 缩 。 


11.encoding 


设置 文件 所 使 用 的 字符 集 ， 以 便 使 用 GUI 工 具 (如 gitk 和 git-gui) 
时 能 够 正确 显示 文件 内 容 。 基 于 性 能 上 的 考虑 ，gitk 默 认 不 检查 该 属 
性 ， 除 非 通 过 gitk 的 偏好 设置 启用 "Support per-file encodings"。 


如 果 没 有 为 文件 设置 encoding 属 性 ， 则 使 用 git.encoding 配 置 变 


量 。 


12.binary 


属性 binary 产 格 来 说 是 一 个 宏 ， 相 当 于 -text-diff。 即 禁止 换行 符 转 
换 ， 以 及 禁止 以 文本 方式 显示 文件 差异 。 


用 户 也 可 以 自 定 义 宏 。 上 自 定 义 宏 只 能 在 工作 区 根 目 录 中 
的 .gitattributes 文 件 中 添加 ， 以 内 置 的 binary 宏 为 例 ， 相 当 于 在 属性 文 
件 中 进行 了 如 下 的 设置 : 


[attr]jbinary-diff-text 


[1] 如 果 设 置 colorui 配 置 变 量 为 tue， 则 针对 所 有 Git 命 令 开 局 颜色 输 
出 o 


41.2” 钧 子 和 模板 
41.2.1 ”Git 钧 子 


Git 的 钩子 脚本 位 于 版 本 库 的 .githooks 目 录 下 ， 当 Git 执 行 特 定 操 作 
时 会 调用 特定 的 钩子 脚本 。 当 版 本 库 通 过 git init 或 git clone 创 建 时 ， 会 
在 .git/hooks 目 录 下 创建 示例 脚本 ， 用 户 可 以 参照 示例 脚本 的 写法 开发 
适合 的 钩子 脚本 。 


钓 子 脚本 要 设置 为 可 运行 ， 并 使 用 特定 的 名 称 。Git 提 供 的 示例 肢 
本 都 带 有 .sample 扩 展 名 ， 是 为 了 防止 被 意外 运行 。 如 采 需 要 局 用 相应 
的 钩子 脚本 ， 需 要 对 其 重 命名 (去 掉 .sample 扩 展 名 ) 。 下 面 分 别 对 可 
用 的 钩子 脚本 逐一 进行 介绍 。 


1.applypatch-msg 
该 钩子 脚本 由 git am 命令 调用 。 在 调用 时 间 该 脚本 传递 一 个 参数 ， 


即 保存 有 提交 说明 的 文件 的 文件 名 。 如 采 该 脚本 运行 失败 (返回 非 零 
值 ) ， 则 git am 命令 在 应 用 该 补丁 之 前 终止 。 


这 个 钧 子 脚本 可 以 修改 文件 中 保存 的 提交 遂 明 ， 以 便 规 范 提交 说 
明 以 符合 项 目的 标准 (如 果 有 的 话 ) 。 如 果 提 交 说 明 不 符合 项 目标 


准 ， 脚 本 直接 以 非 零 值 退出 ， 则 拒绝 提交 。 


Git 提 供 的 示例 脚本 applypatch-msg.sample 只 是 简单 地 调用 commit- 
msg 钧 子 脚本 (如 果 存 在 的 话 ) 。 这 样 通过 git am 命令 应 用 补丁 和 执行 
git commit 一 样 ， 都 会 执行 commit-msg 脚 本 ， 因 此 如 需 定制 ， 请 更 改 


commit-msg 脚 本 。 
2.pre-applypatch 


该 钧 子 脚本 由 git am 命令 调用 。 该 脚本 没有 参数 ， 在 补丁 应 用 后 但 
尚未 提交 前 运行 。 如 采 该 脚本 运行 失败 〈 返 回 非 零 值 ) ， 则 不 会 提交 
已 经 应 用 了 补丁 的 工作 区 文件 。 


这 个 脚本 可 以 用 于 对 应 用 补丁 后 的 工作 区 进行 测试 ， 如 果 测试 没 
有 通过 则 拒绝 提交 。 


Git 提 供 的 示例 脚本 pre-applypatch.sample 只 是 简单 地 调用 pre- 
commit 钧 子 脚本 (如 果 存 在 的 话 )  。 这 样 通过 git am 命令 应 用 补丁 和 
执行 git commit 一 样 都 会 执行 pre-commit 脚 本， 因此 如 需 定 制 ， 请 更 改 


pre-commit 脚 本 。 
3.post-applypatch 


该 钧 子 脚本 由 git am 命令 调用 。 该 脚本 没有 参数 ， 在 补丁 应 用 并 且 
提交 之 后 运行 ， 因 此 该 钩子 脚本 不 会 影响 git am 的 运行 结果 ， 可 以 用 于 


发 送 通知 。 
4.pre-commit 


该 钧 子 脚本 由 git commit 命 令 调 用 。 可 以 通过 传递 --no-verify 参 数 
而 禁用 。 该 脚本 在 获取 提交 说 明之 前 运行 。 如 果 该 脚本 运行 失败 〈 返 
回 非 零 值 ) ，Git 提 区 残 被 终止 。 


该 脚本 主要 用 于 对 提交 数据 的 检查 ， 例 如 对 文件 名 进行 检查 (是 
否 使 用 了 中 文 文件 名 ) ， 或 者 对 文件 内 容 进 行 检查 (是 否 使 用 了 不 规 


范 的 空白 字符 ) 。 


Git 提 供 的 示例 脚本 pre-commit.sample 禁 止 提 交 在 路 径 中 使 用 非 
ASCI 字 符 (如 中 文字 符 ) 的 文件 。 如 果 确 有 使 用 的 必要 ， 可 以 在 Git 
配置 文件 中 设置 配置 变量 hooks.allownonascii 为 true 以 允许 在 文件 名 中 
使 用 非 ASCI 字 符 。Git 提 供 的 该 示例 脚本 也 对 不 规范 的 空白 字符 进行 
检查 ， 如 果 发 现 则 终止 提交 。 


Topgit 为 所 管理 的 版 本 库 设 置 了 自己 的 pre-commit 肢 本， 检查 工作 
的 Topgit 特 性 分 文 是 否 正 确 地 设置 了 Topgit 的 两 个 管理 文件 .topdeps 
和 .topmsg， 以 及 定义 的 分 文 依赖 是 否 存在 着 重复 依赖 和 循环 依赖 等 。 


5.prepare-commit-msg 


该 钩子 脚本 由 git commit 命 令 调用 ， 在 默认 的 提交 信息 准备 完成 后 
但 编辑 器 尚未 启动 之 前 运行 。 


该 脚本 有 1 一 3 个 参数 。 第 一 个 参数 是 包含 提交 说 明 的 文件 的 文件 
名 。 第 二 个 参数 是 提交 说 明 的 来 源 ， 可 以 是 message (由 -m 或 -F 参 数 提 
供 ) ， 可 以 是 template (如 果 使 用 了 -t 参 数 或 由 commit.template 配 置 变 
量 提供 ) ， 或 者 是 merge (如 果 提 交 是 一 个 合并 或 存 
在 .giUMERGE_MSG 文 件 ) ， 或 者 是 squash (如 果 存 
在 .giVSQUASH MSG 文件 ) ， 或 者 是 commit 并 跟着 一 个 提交 SHA1 哈 
希 值 (如 果 使 用 -c、-C 或 --amend 参 数 ) 。 


如 果 该 脚本 运行 失败 (返回 非 零 值 ，，Git 提 交 束 被 终止 。 


该 脚本 用 于 对 提交 说 明 进 行 编辑 ， 并 且 该 脚本 不 会 因为 --no-verify 
参数 被 禁用 。 

Git 提 供 的 示例 脚本 prepare-commit-msg.sample 可 以 用 于 辐 提 区 说 
明 中 磐 入 提交 者 的 签名 ， 或 者 将 来 和 目 merge 的 提交 说 明 中 含 
有 "Conflicts:" 的 行 去 掉 。 


6.commit-msg 


该 钧 子 脚本 由 git commit 命 令 调 用 ， 可 以 通过 传递 --no-verify 参 数 
而 禁用 。 该 脚本 有 一 个 参数 ， 即 包含 有 提交 说 明 的 文件 的 文件 名 。 如 


果 该 脚本 运行 失败 〈 返 回 非 零 值 ) ，Git 提 区 被 终止 。 


该 脚本 可 以 直接 修改 提交 说 明 ， 可 以 用 于 规范 提交 说 明 以 符合 项 
目的 标准 《如果 有 的 话 ) 。 如 果 提 交 说 明 不 符合 标准 ， 可 以 拒绝 提 
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Git 提 供 的 示例 脚本 commit-msg.sample 检 查 提交 说 明 中 出 现 的 相同 
的 含 "Signed-off-by" 的 行 ， 如 果 发 现 重 复 签 名 即 报错 并 终止 提交 。 


Gerrit 服 务 絮 需要 每 一 个 同 其 进行 推送 的 Git 版 本 库 在 本 地 使 用 
Gerrit 提 供 的 commit-msg 钧 子 肢 本， 以便 在 创建 的 提交 中 包含 形 
如 "Change-Id:I..….. "的 变更 集 标 签 。 


7.post-commit 


该 钩子 脚本 由 git commit 命 令 调用 ， 不 之 参数 运行 ， 在 提交 完成 之 
后 被 触发 执行 。 


该 钩子 脚本 不 会 影响 git commit 的 运行 结果 ， 可 以 用 于 发 送 通 知 。 
8.pre-rebase 
该 钩子 脚本 由 git rebase 命 令 调用 ， 用 于 防止 某 个 分 支 参 与 变 基 。 


Git 提 供 的 示例 脚本 pre-rebase.sample 是 针对 Git 项 目 自身 的 情况 而 
开发 的 ， 当 一 个 功能 分 支 已 经 合并 到 next 分 支 后 ， 禁 止 该 分 支 进 行 变 


基 操 作 。 


9.post-checkout 


该 钩子 脚本 由 git checkout 命 令 调用 ， 在 完成 工作 区 更 新 之 后 触发 
执行 。 该 钧 子 脚 本 有 三 个 参数 ， 分 别 是 ， 之 前 的 HEAD 所 指向 的 引 
用 、 新 的 HEAD 所 指向 的 引用 (可 能 和 前 一 个 一 样 也 可 能 不 一 样 ) ， 
以 及 一 个 用 于 表示 此 次 检 出 是 否 是 分 支 检 出 的 标识 (分支 检 出 为 1， 文 
件 检 出 是 0)  。 该 钧 子 脚本 不 会 影响 git checkout 命 令 的 运行 结果 。 


除了 由 git checkout 命 令 调用 外 ， 该 钧 子 脚 本 也 在 git clone 命 令 执行 
后 被 触发 执行 ， 除 非 在 克隆 时 使 用 了 禁止 检 出 的 --no-checkout (-n) 参 
数 。 在 由 git clone 调 用 时 ， 第 一 个 参数 给 出 的 引用 是 空 引用 ， 则 第 二 个 
和 第 二 个 参数 都 为 1 。 


这 个 钩子 一 般 用 于 版 本 库 的 有 效 性 检查 ， 目 动 显 示 和 前 一 个 
HEAD 的 差异 ， 或 者 设置 工作 区 属性 。 


10.post-merge 


该 钧 子 脚本 由 git merge 命 令 调 用 ， 当 在 本 地 版 本 库 完成 git pull 操 
作 后 触发 执行 。 该 钩子 脚本 有 一 个 参数 ， 标 识 合并 是 否 是 一 个 压缩 合 
并 。 该 钩子 脚本 不 会 影响 git merge 命 令 的 运行 结果 。 如 果 合 并 因为 冲 
突 而 失败 ， 则 该 脚本 不 会 执行 。 


该 钧 子 脚 本 可 以 与 pre-commit 钧 子 脚本 一 起 实现 对 工作 区 目录 树 
属性 (如 权限 / 属 主 /ACL 等 ) 的 保存 和 恢复 。 参 见 Git 源 码 文 件 
contrib/hooks/setgitperms.perl 中 的 示例 。 


11.pre-receive 


该 钩子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 在 远程 服务 器 上 开始 批量 更 新 引用 之 前 ， 该 
钧 子 脚本 被 触发 执行 。 该 钧 子 脚 本 的 退出 状态 决定 了 更 新 引用 的 成 功 


与 否 。 


该 钩子 脚本 在 接收 (receive) 操作 中 只 执行 一 次 。 传 递 参数 不 通 
过 命令 行 ， 而 是 通过 标准 输入 进行 传递 。 通 过 标准 输入 传递 的 每 一 行 
的 语法 格式 为 : 


<old-value> <new-value> <ref-name> 


<old-value> 是 引用 更 新 前 的 老 的 对 象 ID，<new-value> 是 引用 
即将 更 新 到 的 新 的 对 象 ID，<ref-name> 是 引用 的 全 名 。 当 创建 一 个 
新 引用 时 ，<old-value> 是 40 个 0。 


如 有 条 该 钩子 脚本 以 非 零 值 退出 ， 一 个 引用 也 不 会 更 新 。 如 林 该 脚 
本 正常 退出 ， 每 一 个 单独 的 引用 的 更 新 仍 有 可 能 被 update 钧 子 所 阻 
i 


标准 输出 和 标准 错误 都 重 定向 到 在 另外 一 端 执 行 的 git send-pack 
上 ， 所 以 可 以 直接 通过 echo 命 令 向 用 户 传递 信息 。 


12.update 


该 钧 子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 在 远程 服务 器 上 更 新 引用 时 ， 该 钧 子 脚 本 被 
触发 执行 。 该 钧 子 脚本 的 退出 状态 决定 了 更 新 引用 的 成 功 与 否 。 


该 钩子 脚本 在 每 一 个 引用 更 新 的 时 候 都 会 执行 一 次 。 该 脚本 有 三 


参数 1: 要 更 新 的 引用 的 名 称 。 
参数 2: 引用 中 保存 的 旧 对 象 名 称 。 
参数 3: 将 要 保存 到 引用 中 的 新 对 象 名 称 。 


正常 退出 (返回 0) 则 人 允许 更 新 该 引用 ， 而 以 非 零 值 退出 则 禁止 
git-receive-pack 更 狐 该 引用 。 


该 钩子 脚本 可 以 用 于 防止 某 些 引用 被 强制 更 新 ， 因 为 该 脚本 可 以 
通过 检查 新 旧 引 用 对 象 是 否 存在 继承 关系 ， 从 而 提供 更 为 细致 的 * 非 快 
进 式 推送 ”的 授权 。 


该 钩子 脚本 也 可 以 用 于 记录 (如 用 邮件) 引用 变更 历史 oldnew 。 
然而 因为 该 脚本 不 知道 完整 的 引用 更 新 ， 所 以 可 能 会 导致 每 一 个 引用 
发 送 一 封 邮件 。 因 此 如 果 要 发 送 通 知 邮件 ， 可 能 post-receive 钓 子 脚本 
更 为 适合 。 


另外 ， 该 脚本 可 以 实现 基于 路 径 的 授权 。 


标准 输出 和 标准 错误 都 重 定 和 癌 到 在 另外 一 端 执行 的 git send-pack 
上 ， 所 以 可 以 直接 通过 echo 命 令 辐 用 户 传递 信息 。 
Git 提 供 的 示例 脚本 update.sample 展 示 了 对 多 种 危险 的 Git 操 作 行为 


进行 控制 的 可 行 性 。 


只 有 将 配置 变量 hooks.allowunannotated 设 置 为 true 才 允许 推送 轻 量 
级 里 程 碑 〈 不 带 说 明 的 里 程 碑 ) 。 


只 有 将 配置 变量 hooks.allowdeletebranch 设 置 为 true 才 人 允许 删除 分 
支 o 


如 果 将 配置 变量 hooks.denycreatebranch 设 置 为 true 则 不 允许 创建 新 
a 


只 有 将 配置 变量 hooks.allowdeletetag 设 置 为 true 才 允许 删除 里 程 
碑 。 


只 有 将 配置 变量 hooks.allowmodifytag 设 置 为 true 才 允许 修改 里 程 


相 比 Git 的 示例 脚本 ，Gitolite 服 务 硕 为 其 管理 的 版 本 库 设 置 的 
update 钩 子 脚本 更 实用 也 更 强大 。Gitolite 实 现 了 用 户 认证 ， 并 通过 检 
查 授权 文件 ， 实 现 基 于 分 文 和 路 径 的 写 操作 授权 ， 等 等 。 具 体内 容 请 
参见 本 书 第 5 篇 “第 30 章 Gitolite 服 务 架设 ”的 相关 内 容 。 


13.post-receive 


该 钧 子 脚本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 ， 并 且 在 远程 服务 器 上 的 所 有 引用 都 更 新 完毕 后 ， 
该 钧 子 脚本 被 触发 执行 。 


该 钩子 脚本 在 接收 (receive) 操作 中 只 执行 一 次 。 该 脚本 不 通过 
命令 行 传递 参数 ， 但 是 像 pre-receive 钧 子 脚本 那样 ， 通 过 标准 输入 以 相 
同 格式 获取 信息 。 


该 钧 子 脚本 不 会 影响 git-receive-pack 的 结果 ， 因 为 调用 该 脚本 时 工 
作 已 经 完成 。 


该 钧 子 脚本 胜 过 post-update 脚 本 之 处 在 于 它 可 以 获得 所 有 引用 
的 老 的 和 新 的 值 ， 以 及 引用 的 名 称 。 


标准 输出 和 标准 错误 都 重 定向 到 在 另外 一 端 执 行 的 git send-pack 
上 ， 所 以 可 以 直接 通过 echo 命 令 向 用 户 传递 信息 。 


Git 提 供 的 示例 脚本 post-receive.sample 引 入 了 contrib/hooks 目 孙 下 
的 名 为 post-receive-email 的 示例 脚本 (默认 被 注释 ) ， 以 实现 发 送 通知 
邮件 的 功能 。 


Gitolite 服 务 器 要 对 其 管理 的 Git 版 本 库 设 置 post-receive 钧 子 脚本 ， 
以 实现 当 版 本 库 有 变更 后 将 数据 传输 到 各 个 镜像 版 本 库 。 


14.post-update 


该 钧 子 脚 本 由 远程 版 本 库 的 git receive-pack 命 令 调 用 。 当 从 本 地 版 
本 库 完 成 一 个 推送 之 后 ， 即 当 所 有 引用 都 更 狐 完 毕 后 ， 在 远程 服务 磊 
上 该 钩子 脚 本 被 触发 执行 。 


该 脚本 接收 不 定 长 的 参数 ， 每 个 参数 实际 上 束 是 已 经 成 功 更 新 的 
引用 和 名。 


该 钩子 脚本 不 会 影响 git-receive-pack 的 结果 ， 因 此 主要 用 于 通知 。 


钧 子 脚 本 post-update 虽 然 能 够 提供 哪些 引用 被 更 新 了 ， 但 是 该 脚 
本 不 知道 引用 更 新 前 后 的 对 象 SHA1 哈 希 值 ， 所 以 在 这 个 脚本 中 不 能 记 
录 形 如 old..new 的 引用 变更 施 围 。 而 钓 子 脚本 post-receive 知 道 引用 更 新 
前 后 的 对 象 ID， 因 此 更 适合 于 此 种 场合 。 


标准 输出 和 标准 错误 都 重 定 辐 到 在 另外 一 端 执 行 的 git send-pack 
上 ， 所 以 可 以 直接 通过 echo 命 令 辐 用 户 传递 信息 。 
Git 提 供 的 示例 脚本 postrupdate.sample 会 运行 git update-server-info 


命令 ， 以 更 新 哑 协 议 需要 的 索引 文件 。 如 采 通 过 号 协议 共 孚 版 本 库 ， 
放 该 局 用 该 钩子 脚本 。 


一 


15.pre-auto-gc 


该 钩子 脚本 由 git gc--auto 命 令 调用 ， 不 带 参数 运行 ， 如 果 以 非 零 
值 退出 会 导致 git gc--auto 被 中 断 。 


16.post-rewrite 


该 钧 子 脚本 由 一 些 重 写 提交 的 命令 调用 ， 如 git commit--amend 、 
git rebase， 而 git-filter-branch 当 前 尚未 调用 该 钧 子 脚本 。 


该 脚本 的 第 一 个 参数 用 于 判断 调用 来 目 哪个 命令 ， 当 前 有 amend 
和 rebase 了 两 个 取 值 ， 也 可 能 将 来 会 传递 其 他 的 更 多 命令 相关 的 参数 。 


该 脚本 通过 标准 输入 接收 一 个 重 写 提 区 列表 ， 每 一 行 输入 的 格式 
如 下 : 


<old-shai> <new-sha1i>[<extra-info>] 


前 两 个 是 旧 的 和 新 的 对 象 SHA1 哈 希 值 。 而 <extra-info > 参数 是 和 
调用 命令 相关 的 ， 当 前 该 参数 为 空 。 


41.2.2” ”Git 模板 


当 执 行 git init 或 git clone 创 建 版 本 库 时 ， 会 目 动 在 版 本 库 中 创建 钩 
子 脚本 (.git/hooks/*) 、 忽 略 文件 (.git/info/exclude) 及 其 他 文件 ， 实 
际 上 这 些 文件 均 挝 贝 目 模板 目 永 。 如 果 需 要 本 地 版 本 库 使 用 定制 的 钩 
子 脚 本 等 文件 ， 直 接 在 模板 目录 内 创建 (文件 或 符号 链接 ) 会 事 半 功 


倍 。 


Git 按 照 下 列 顺序 第 一 个 确认 的 路 径 即 为 模板 目录 。 


(1) 如 果 执 行 git init 或 git clone 命 令 时 ， 提 供 --template=<DIR> 
参数 ， 则 使 用 指定 的 目录 作为 模板 目录 。 


(2) 由 环境 变量 $GIT_TEMPLATE_DIR 指 定 的 模板 目录 。 


(3) 由 Git 配 置 变量 init.templatedir 指 定 的 模板 目录 。 


(4) 默认 的 模板 目录 ， 根 据 Git 安 装 路 径 的 不 同 可 能 位 于 不 同 的 
目录 下 。 可 以 通过 下 面 命 令 确 认 其 实际 位 置 : 


$echo$(dirname$(dirname$(git--html-path)))/git-core/templates 
/usr/share/git-core/templates 


如 果 在 执行 版 本 库 初 始 化 时 传递 了 空 的 模板 路 径 ， 则 不 会 在 版 本 
库 中 创建 钩子 脚本 等 文件 。 


$git init--template=simplegit 
Initialized empty Git repository 
in/path/to/my/workspace/simplegit/.git/ 


执行 下 面 的 命令 ， 查 看 新 创建 的 版 本 库 .git 目 录 下 的 文件 。 


EAD ong ohio tor neta 

可 以 看 到 不 使 用 模板 目录 创建 的 版 本 库 下 面 的 文件 少 的 可 怜 。 而 
通过 对 模板 目录 下 的 文件 的 定制 ， 可 以 使 得 在 建立 的 版 本 库 中 包含 巴 
先 设置 好 的 钩子 脚本 、 忽 略 文件 、 必 性 文件 甚至 config 配 置 文件 等 。 
这 给 对 服务 器 或 对 版 本 库 操作 有 特殊 要 求 的 项 目 带 来 了 方便 。 


41.3 ” 稀 足 检 出 和 浅 克 隆 
41.3.1 稀疏 检 出 


从 1.7.0 版 本 开始 Git 提 供 稀 玖 检 出 的 功能 。 所 谓 稀 玖 检 出 就 是 ， 本 
地 版 本 库 检 出 时 不 检 出 全 部 ， 只 将 指定 的 文件 从 本 地 版 本 库 中 检 出 到 
工作 区 ， 而 其 他 未 指定 的 文件 则 不 予 检 出 (即使 这 些 文件 存在 于 工作 
区 ， 其 修改 也 会 被 忽略 ) 。 


要 想 实现 稀疏 检 出 的 功能 ， 必 须 同 时 设置 core.sparseCheckout 配 置 
变量 ， 并 存在 文件 .git/info/sparse-checkout。 即 首先 要 设置 Git 配 置 变量 
core.sparseCheckout 为 tue， 然 后 编辑 .git/info/sparse-checkout 文 件 ， 将 
要 检 出 的 目录 或 文件 的 路 径 写 入 其 中 。 其 中 文件 .git/info/sparse- 
checkout 的 格式 束 和 .gitignore 文 件 格 式 一 样 ， 路 径 可 以 使 用 通配符 。 


稀疏 检 出 是 如 何 实现 的 呢 ? 实际 上 Git 在 index ( 即 暂 存 区 ) 中 为 每 
个 文件 提供 一 个 名 为 skip-worktree 的 标志 位 ， 默 认 这 个 标志 位 处 于 关 
闭 状态 。 如 果 开 启 该 标志 位 ， 则 无 论 工作 区 对 应 的 文件 存在 与 否 ， 或 
者 是 否 被 修改 ，Git 都 认为 工作 区 该 文件 的 版 本 是 最 新 的 、 无 变化 的 。 
Git 通 过 配置 文件 .git/info/sparse-checkout 定 义 一 个 要 检 出 的 目录 和 /或 文 
件 列表 ， 当 前 Git 的 git read-tree 命 令 及 其 他 基于 合并 的 命令 (git 


merge、git checkout 等 ) 能 够 根据 该 配置 文件 更 新 的 mdex 中 文件 的 
skip-worktree 标 志 位 ， 实 现 版 本 库 文 件 的 稀 朴 检 出 。 


先 在 工作 区 /path/to/my/workspace 中 创建 一 个 示例 版 本 库 sparse1， 
创建 后 的 Sparsel 版 本 库 中 包含 如 下 内 容 : 


$1s-F 

doci/doc2/doc3/ 

$git ls-files-s-v 

H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 
doci/readme. txt 

H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 
doc2/readme. txt 

H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0 
doc3/readme. txt 


即 版 本 库 sparsel 中 包含 三 个 目录 doc1、doc2 和 doc3。 命 令 git ]s- 
files 的 -s 参 数 用 于 显示 对 象 的 SHA1 哈 希 值 及 所 处 的 暂 存 区 的 编号 。 而 - 
V 参 数 则 显示 工作 区 文件 的 状态 ， 每 一 行 命令 输出 的 第 一 个 字符 即 是 文 
件 状 态 : 字母 H 表 示 文 件 已 被 暂 存 ， 如 条 是 字母 S 则 表示 该 文件 skip- 
worktree 的 标志 位 已 开局 。 


下 面 我 们 束 来 体验 一 下 稀 玻 检 出 的 功能 。 


(1) 修改 版 本 库 的 Git 配 置 变量 core.sparseCheckout， 将 其 设置 为 


true ° 


$git config core.sparseCheckout true 


(2) 设置 .git/info/sparse-checkout 的 内 容 ， 如 下 : 


$printf"doci\ndoc3\n"> .git/info/sparse-checkout 
$cat .git/info/sparse-checkout 

doc1 

doc3 


(3) 执行 git checkout 命 令 后 ， 会 发 现 工 作 区 中 的 doc2 目 录 不 见 
了 o 
$git checkout 


$1s-F 
doc1i/doc3/ 


(4) 这 时 如 有 果 用 git ls-files 命 令 查 看 ， 会 发 现 doc2 目 录 下 的 文件 被 
设置 了 skip-worktree 标 志 。 
$git ls-files-v 
H doci/readme.txt 


S doc2/readme. txt 
H doc3/readme.txt 


(5) 修改 .git/info/sparse-checkout 的 内 容 ， 如 下 : 


$printf"doc3\n"> .git/info/sparse-checkout 
$cat .git/info/sparse-checkout 
doc3 


(6) 执行 git checkout 命 令 后 ， 会 发 现 工 作 区 中 的 doc1 目 录 也 不 见 
T o 


$git checkout 
$1s-F 
doc3/ 


(7) 这 时 如 果 用 git ls-files 命 令 查 看 ， 会 发 现 docl1 和 doc2 目 录 下 的 
文件 都 被 设置 了 skip-worktree 标 志 。 
$git ls-files-v 
S doci/readme.txt 


S doc2/readme. txt 
H doc3/readme.txt 


(8) 修改 .git/info/sparse-checkout 的 内 容 ， 使 之 包含 一 个 星 号 ， 即 
在 工作 区 检 出 所 有 的 内 容 。 


$printf "*\n"> .git/info/sparse-checkout 
$cat .git/info/sparse-checkout 


(9) 执行 git checkout， 会 发 现 所 有 目录 又 都 回来 了 。 


$git checkout 
$1s-F 
doci/doc2/doc3/ 


文件 .giUinfo/sparse-checkout 的 格式 类 似 于 .gitignore 的 格式 ， 也 文 
持 用 感叹 号 实现 反 同 操作 。 例 如 不 检 出 目录 doc2 下 的 文件 ， 而 检 出 其 
他 文件 ， 可 以 使 用 下 面 的 语法 (注意 顺序 不 能 写 反 ) : 


1doc2/ 


注意 如 果 使 用 命令 git checkout--<file>...... ， 即 不 是 切换 分 支 而 
是 用 分 支 中 的 文件 替换 暂 存 区 和 工作 区 ， 则 忽略 skip-worktree 标 志 。 
例如 下 面 的 操作 中 ， 虽 然 doc2 被 设置 为 不 检 出 ， 但 是 执行 git checkout. 
命令 后 ， 所 有 的 目录 还 是 都 被 检 出 了 。 


$git checkout. 
$1s-F 
doci/doc2/doc3/ 
$git ls-files-v 

H doci/readme.txt 
S doc2/readme.txt 
H doc3/readme.txt 


如 有 果 修 改 doc2 目 录 下 的 文件 ， 或 者 在 doc2 目 录 下 添加 新 文件 ，Git 
会 视而不见 。 
$echo hello> >doc2/readme.txt 
$git status 


#0n branch master 
nothing to commit(working directory clean) 


若 此 时 通过 取消 core.sparseCheckout 配 置 变量 的 设置 而 关闭 稀疏 检 
出 ， 也 不 会 改变 目录 doc2 下 的 文件 的 skip-worktree 标 志 。 这 种 情况 或 者 
通过 git update-index--no-skip-worktree--<file > .….. 来 更 改 index 中 对 应 
文件 的 skip-worktree 标 志 ， 或 者 重新 启用 稀 疏 检 出 更 改 相 应 文件 的 检 
出 状态 。 


如 果 在 克隆 一 个 版 本 库 时 只 希望 检 出 部 分 文件 或 目录 ， 可 以 在 执 
行 克 隆 操 作 的 时 候 使 用 --no-checkout 或 -n 参 数 ， 不 进行 工作 区 文件 的 检 
出 。 例 如 下 面 的 操作 从 前 面 示例 的 sparsel 版 本 库 殉 隆 到 sparse2 中 ， 不 
进行 工作 区 文件 的 检 出 。 


$git clone-n Sparse1 Sparse2 
Cloning into sparse2... 
done. 


检 出 完成 后 可 以 发 现 sparse2 的 工作 区 是 空 的 ， 而 且 版 本 库 中 也 不 
存在 index 文 件 。 如 果 执 行 git status 命 令 会 看 到 所 有 文件 都 被 标识 为 删 
除 。 

$cd sparse2 
$git status-s 
D doci/readme.txt 


D doc2/readme.txt 
D doc3/readme.txt 


如 果 布 望 通过 稀 芷 检 出 的 功能 ， 只 检 出 其 中 一 个 目录 如 doc2， 可 
以 用 如 下 方法 实现 : 
$git config core.sparseCheckout true 


$printf "doc2\n"> .git/info/sparse-checkout 
$git checkout 


之 后 看 到 工作 区 中 检 出 了 doc2 目 孙 ， 而 其 他 文件 被 设置 了 skip- 


worktree 标 志 。 


$1s-F 

doc2/ 

$git ls-files-v 
S doci/readme.txt 
H doc2/readme.txt 
S doc3/readme.txt 


41.3.2” 浅 克隆 


上 一 节 介 绍 的 稀 朴 检 出 ， 可 以 部 分 检 出 版 本 库 中 的 文件 ， 但 是 版 
本 库 本 吴 仍 然 包含 所 有 的 文件 和 历史 。 如 果 只 对 一 个 大 的 版 本 库 的 最 
近 的 部 分 历史 提交 奈 兴 趣 ， 而 不 想 殉 隆 整个 版 本 库 ， 稀 芷 检 出 十 解决 
不 了 这 个 问题 的 ， 应 采用 本 市 介绍 的 浅 克 隆 。 


实现 版 本 库 的 浅 克 隆 非常 简单 ， 只 需要 在 执行 git clone 或 git fetch 
操作 时 用 --depth< depth> 参数 设 定 要 获取 的 历史 提交 的 深度 (< depth 
> 大 于 0) ， 就 会 把 源 版 本 库 分 文 上 最 近 的 < depth> +1 个 历史 提交 作 
为 新 版 本 库 的 全 部 历史 提交 。 


通过 浅 克隆 方式 克隆 出 来 的 版 本 库 ， 每 一 个 提交 的 SHA1 哈 布 值 和 
源 版 本 库 都 相同， 包括 提交 的 根 市 点 也 是 如 此 ， 但 是 Git 通 过 特殊 的 实 
现 ， 使 得 浅 克 隆 的 根 市 点 提交 看 起 来 没有 父 提交 。 正 因为 浅 元 隆 的 所 
区 对 象 的 SHA1 哈 希 值 和 源 版 本 库 一 怪 ， 所 以 浅 克 隆 版 本 库 可 以 执行 
git fetch 或 git pull 从 源 版 本 库 获 取 新 的 提交 。 但 是 浅 殉 隆 版 本 库 也 存在 
着 很 多 限制 ， 如 : 


不 能 从 浅 克 隆 版 本 库 克 隆 出 新 的 版 本 库 。 


其 他 版 本 库 不 能 从 浅 克 隆 版 本 库 中 获取 提交 。 


其 他 版 本 库 不 能 推送 提交 到 浅 克 隆 版 本 库 。 


不 要 从 浅 克隆 版 本 库 推送 提交 至 其 他 版 本 库 ， 除 非 确认 推送 的 目 
标 版 本 库 包 含 浅 苑 隆 版 本 库 中 缺失 的 全 部 历史 提交 ， 人 否则 会 因为 目标 
版 本 库 包 含 不 完整 的 提交 历史 而 导致 版 本 库 无 法 操作 。 


在 浅 克 隆 版 本 库 中 执行 合并 操作 时 ， 如 果 所 合并 的 提交 出 现在 浅 
克隆 版 本 库 的 历史 中 ， 则 可 以 顺利 合并 ， 人 否则 会 出 现 大 量 的 冲突 ， 融 
好 像 和 无 关 的 历史 进行 合并 一 样 。 


由 于 浅 克 隆 包 含 上 述 限 制 ， 因 此 浅 克 隆 一 般 用 于 对 远程 版 本 库 的 
查看 和 人 研究， 如 果 在 浅 克 隆 版 本 库 中 进行 了 提交 ， 最 好 通过 git format- 
patch 命 令 导出 为 补丁 文件 再 应 用 到 远程 版 本 库 中 。 


下 面 的 操作 使 用 git clone 命 令 创建 一 个 浅 殉 隆 。 注 意 ; 源 版 本 库 如 
果 是 本 地 版 本 库 ， 就 要 使 用 季 e:// 协 议 ， 奉 直接 使 用 本 地 路 径 则 不 会 实 
现 浅 克隆 。 


$git clone--depth 2 file:///path/to/repos/hello-world.git 
shallow1 


然后 进入 到 本 地 克隆 目 未 中， 会 看 到 当前 分 文 上 只 有 3 个 提交 。 


$git 1og--oneline 

c4acab2 Translate for Chinese. 
683448a Add I18N support. 
d81896e Fix typo:-help to--help. 


查看 提交 的 根 广 点 d81896e， 会 看 到 该 提交 实际 上 也 包含 父 提 交 。 


$git cat-file-p HEADAA 

tree f9d7f6boaf6f3fffa74eb995f1d781d3c4876b25 

parent 10765a7ef46981a73d578466669f6e17b73ac7e3 
author User1<uUser1Q@sun.ossxp.com>1294069736+0800 
committer user2<user2@moon.ossxp.com>1294591238+0800 
Fix typo:-help to--help. 


而 查看 该 提交 的 父 提 交 ，Git 会 报错 。 


$git log 10765a7ef46981a73d578466669f6e17b73ac7e3 
fatal:bad object 10765a7ef46981a73d578466669f6e17b73ac7e3 


对 于 正常 的 Git 版 本 库 来 说 ， 如 末 对 和 象 库 中 丢失 一 个 提交 绝对 十 大 
问题 ， 版 本 库 不 可 能 补正 党 使用。 而 浅 殉 隆 之 所 以 看 起 来 一 切 正 前 ， 
征 因为 Git 使 用 了 类 似 媒 接 (下 一 节 即 将 介绍 ) 的 技术 。 


在 浅 克 隆 版 本 库 中 存在 一 个 文件 .git/shallow， 这 个 文件 中 罗列 了 
应 该 被 视 为 提交 根 节点 的 提交 SHA1 哈 希 值 。 查 看 这 个 文件 会 看 到 提交 
d81896e 正 在 其 中 : 


$cat .git/shallow 

b56bb510a947651e4717b356587945151ac32166 
d81896e60673771ef1873b27a33f52df75f70515 
e64f3a216d346669b85807ffcfb23a21f9c5c187 


列 在 .git/shallow 文 件 中 的 提交 会 构建 出 对 应 的 怒 接 提交 ， 使 用 类 
似 媒 接 文件 .giVinfo/grafts (下 节 讨 论 ) 的 机 制 ， 当 Git 访 问 这 些 对 象 时 


忠 好 像 这 些 对 象 是 没有 父 提交 的 根 广 点 一 样 。 


41.4 ”嫁接 和 替换 


41.4.1 ”提交 嫁接 


提交 嫁接 可 以 实现 在 本 地 版 本 库 上 将 两 条 完全 不 同 的 提交 线 (分 
支 ) 嫁接 (连接 ) 到 一 起 。 对 于 一 些 在 迁移 版 本 控制 系统 时 遇 到 困难 
的 项 目 ， 该 技术 会 非常 有 帮助 。 例 如 Linux kernel 本 里 的 版 本 控制 系统 
在 迁移 到 Git 上 时 ， 尚 没有 任何 工具 可 以 将 Linux 的 提交 历史 从 旧 的 
Bitkeeper 版 本 控制 系统 中 导出 ， 直 到 后 来 通过 bkcvs 将 Bitkeeper 上 的 
Linux 历 史 提 区 导入 到 Git 中 。 如 何 将 新 旧 两 条 开发 线 连接 到 一 起 呢 ? 
于 是 束 发 明了 提交 媒 接 ， 以 实现 新 旧 两 条 开发 线 的 合并 ， 这 样 Linux 开 
发 者 就 可 以 在 一 个 开发 分 文中 由 最 新 的 提交 追踪 到 原来 位 于 Bitkeeper 
中 的 提交 多。 


是 交 尹 接 是 通过 在 版 本 库 中 创建 .giVinfo/grafts 文 件 来 实现 的 。 该 
文件 每 一 行 的 格式 为 : 


<commit sha1i> <parent shai>[<parent shai>]* 


用 空格 分 开 各 个 字段 ， 其 中 第 一 个 字段 足 一 个 提交 的 SHA1 险 项 
值 ， 而 后 面 用 空格 分 开 的 其 他 SHA1 哈 希 值 则 作为 该 提交 的 父 提交 。 把 


一 个 提交 线 的 根 广 点 作为 第 一 个 字段 ， 第 二 个 提交 线 的 顶 市 点 作为 第 


二 个 字段 ， 束 实现 了 两 个 提交 线 的 怒 授 ， 看 起 来 束 像 古 一 条 提交 线 
本 


在 本 书 第 6 篇 第 35 章 的 “35.4 Git 版 本 库 整 理 ” 中 介绍 的 git filter- 
branch 命 令 在 整理 版 本 库 时 ， 如 采 发 现存 在 .git/info/grafts 则 会 在 物理 上 
完成 提交 的 怒 接 ， 实 现 怒 接 的 永久 生 戏 。 


[1| https://git.wiki.kernel.org/index.php/GraftPoint 


41.4.2 ”提交 替换 


提交 蔡 换 是 在 1.6.5 或 更 新 版 本 的 Git 中 提供 的 功能 ， 和 提交 怒 接 类 
似 ， 不 过 提交 车 换 不 是 用 一 个 提交 来 仿 洲 成 男 外 一 个 提交 的 父 提交 ， 
而 是 直接 替换 另外 的 提交 ， 在 不 影响 其 他 提交 的 基础 上 实现 对 历史 提 
交 的 修改 。 


提交 替换 是 通过 在 特殊 命名 空间 .gitrefs/replace/ 下 定义 引用 来 实现 
的 。 引 用 的 名 称 是 要 被 奉 换 掉 的 提交 SHA1 哈 希 值 ， 而 引用 文件 的 内 容 
(引用 所 指向 的 提交 ) 就 是 用 于 替换 的 〈 正 确 的 ) 提交 SHA1 哈 希 值 。 
由 于 提交 替换 通过 引用 进行 定义 ， 因 此 可 以 在 不 同 的 版 本 库 之 间 传 
递 ， 而 不 像 提 交 妈 接 只 能 在 本 地 版 本 库 中 使 用 。 


Git 提 供 git replace 命 令 来 管理 提交 蔡 换 ， 用 法 如 下 : 


法 1:git replace[-f]<object><replacement> 
法 2:git replace-d<object>... 
法 3:git replace-1[<pattern>] 


其 中 : 


用 法 1 用 于 创建 提交 蔡 换 ， 即 在 .git/refs/replace 目 录 下 创建 各 为 < 
object> 的 引用 ， 其 内 容 为 <replacement>。 如 果 使 用 -{ 参 数 ， 还 允许 


级 联 蔡 换 ， 即 用 于 替换 的 提交 可 以 是 另外 一 个 已 经 在 .gitrefs/replace 中 
定义 的 替换 。 


用 法 2 用 于 删除 已 经 定义 的 替换 。 


用 法 3 显示 已 经 存在 的 提交 奉 换 。 


提交 替换 可 以 被 大 部 分 Git 命 令 理 解 ， 除 了 一 些 针 对 被 蔡 换 的 提交 
使 用 --no-replace-objects 参 数 的 命令 。 例 如 : 


当 提 交 foo 被 提交 bar 玲 换 后 ， 显 示 示 被 蔡 换 前 的 foo 提 交 : 


$git--no-replace-objects cat-file commit foo 


,, ,foo 的 内 容 ， 


不 使 用 --no-replace-objects 参 数 ， 则 访问 foo 会 显示 替换 后 的 bar 提 


N| 
bb 


$git cat-file commit foo 


. . bar 的 内 容 ... 


提 区 替换 使 用 引用 进行 定义 ， 因 此 可 以 通过 git fetch 和 git push 在 版 
本 库 之 间 传 递 。 但 因为 默认 Git 只 同步 里 程 牧 和 分 文 ， 因 此 需要 在 命令 
中 显 式 地 给 出 提交 替换 的 引用 表达 式 ， 如 : 


$git fetch origin refs/replace/* 
$git push origin refs/replace/* 


提交 替换 也 可 以 实现 两 个 分 文 的 嫁接 。 例 如 要 将 分 文 A 嫁 接 到 B 
上 ， 就 相当 于 将 分 支 A 的 根 提 交 <BRANCH A_ROOT> 的 父 提 交 设 置 
为 分 支 B 的 最 新 提交 <BRANCH _B_CURRENT>。 可 以 先 创 建 一 个 新 


提交 <BRANCH A_NEW_ROOT> ， 其 父 提 交 设 置 为 < 


BRANCH B_CURRENT> 而 提交 的 其 他 字段 和 <BRANCH _A_ROOT 
> 完全 一 致 。 然 后 设置 提交 替换 ， 用 <BRANCH A _NEW_ROOT> 替 


换 <BRANCH A ROOT> 即 可 。 


可 以 使 用 下 面 的 命令 创建 <BRANCH A NEW_ROOT>， 注意 
用 实际 值 替换 下 面 命 令 中 的 <BRANCH _A_ROOT> 和 < 


BRANCH B CURRENT>。 


$git cat-file commit<BRANCH A ROOT> | 
sed-e "/^tree/a\ 


parent $(git rev-parse <BRANCH B CURRENT>)" | 
git hash-obiject ~t commit ~w -~-"stdin 


其 中 git cat-file commit 命令 用 于 显示 提交 的 原始 信息 ，sed 命令 用 于 向 原始 提 
交 中 插入 一 条 parent SHA1..， 的 语句 ， 而 命令 9it hash-object 是 一 个 Git 底层 命 
令 ， 可 以 将 来 自 标准 输入 的 内 容 创建 为 一 个 新 的 提交 对 象 

上 面 命令 的 输出 即 是 <BRANCH BA NEW ROOT> 的 值 。 执 行 下 面 的 替换 命令 ， 完 成 两 个 


p be ey 
分 支 的 嫁接 


$ git replace <BRANCH A ROOT> <BRANCH A NEW ROOT> 


41.5 _Git 评 注 


从 1.6.6 版 本 开始 ，Git 提供 了 一 个 git notes 命令 可 以 为 提交 添加 评注 ， 在 不 改变 
提交 对 象 的 情况 下 ， 实 现在 提交 说 明 的 后 面 附加 评注 。 图 41-1 展示 了 Github “利用 git 
notes 实现 的 显示 评注 (如果 存在 的 话 》 和 添加 评注 的 界面 。 


meeth com eats-tom otdeme_commtt. Ej 17 Die coose 


于 se LL01 Worn WERSION 下 | 
"datire VINASIOS "<vernicny” 
enate 
Git Notes © 
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图 41-1 Github 上 显示 和 添加 评注 


41.5.1 评注 的 奥秘 


实际 上 Git 的 评 广 可 以 针对 任何 对 象 ， 而 且 评注 的 内 容 也 不 限于 文字 ， 因 为 评注 的 内 容 
保存 在 Git 对 象 库 中 的 一 个 blob 对 象 中 。 不 过 评注 目前 最 主要 的 应 用 还 是 在 提交 说 明 后 添加 


文字 评注 。 


在 第 2 篇 第 11 章 的 “11.4.6 二 分 查找 ”中 用 到 的 gitdemo-commit-tree 版 
本 库 实际 上 就 包含 了 提交 评注 ， 只 不 过 之 前 尚未 将 评注 获取 到 本 地 版 


本 库 而 已 。 如 果 工 作 区 中 的 gitdemo-commit-tree 版 本 库 已 经 不 存在 了 ， 
可 以 使 用 下 面 的 命令 从 Github 上 再 克隆 一 个 : 


$git clone-q git://github.com/ossxp-com/gitdemo-commit-tree.git 
$cd gitdemo-commit-tree 


执行 下 面 的 命令 ， 碍 看 最 后 一 次 提交 的 提交 说 明 : 


$git lo0g-1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Dec 9 16:07:11 2010+0800 

Add Images for git treeview. 
Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


下 面 为 默认 的 origin 和 远程 版 本 库 表 添加 一 个 引用 获取 表达 式 ， 以 全 
在 执行 git fetch 命 令 时 能 够 同步 评注 相关 的 引用 。 命 令 如 下 : 


$git config--add remote.origin.fetch refs/notes/*:refs/notes/* 


执行 git fetch 会 获取 到 一 个 新 的 引用 refs/notes/commits， 如 下 : 


$git fetch 

remote:Counting objects:6,done. 

remote:Compressing objects:100%(5/5),done. 
remote:Total 6(delta 0),reused 0(delta 0) 

Unpacking objects:100%(6/6),done. 

From git://github.com/ossxp-com/gitdemo-commit-tree 
*[new branch]refs/notes/commits->refs/notes/commits 


当 获 取 新 的 评注 相关 的 引用 之 后 ， 再 来 查看 最 后 一 次 提交 的 提交 
说 明 。 下 面 的 命令 输出 中 ， 提 交 说 明 的 最 后 两 行 就 是 附加 的 提交 评 
注 。 


$git lo0g-1 

commit 6652aQdce6a5067732c00ef0a220810a7230655e 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Thu Dec 9 16:07:11 2010+0800 

Add Images for git treeview. 
Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 
Notes: 

Bisect test:Bad commit,for doc/B.txt exists. 


附加 的 提交 评注 来 自 于 哪里 呢 ? 显然 应 该 和 刚刚 获取 到 的 引用 相 
关 。 查 看 一 下 获取 到 的 最 新 引用 ， 会 发 现 引 用 refs/notes/commits 指 问 
的 是 一 个 提交 对 象 。 
$git show-ref refs/notes/commits 
6f01cdc59004892741119318ceb2330d6dcocef1 refs/notes/commits 


$git cat-file-t refs/notes/commits 
commit 


既然 新 获取 的 评注 引用 是 一 个 提交 对 象 ， 那 么 就 应 该 能 够 查看 评 
注 引 用 的 提交 日 志 : 


$git log--stat refs/notes/commits 

commit 6fO1icdc59004892741119318ceb2330d6dc0Ocef1 
Author:Jiang Xin<jiangxin@ossxp.com> 

Date:Tue Feb 22 09:32:10 2011+0800 

Notes added by 'git notes add' 
6652a0dce6a5067732c00ef0a220810a7230655e | 1+ 

1 files changed,1 insertions(+),0 deletions(-) 
commit 9771e1076d2218922acc9800f23d5e78d5894a9f 


Author:Jiang Xin<jiangxin@ossxp.com> 
Date:Tue Feb 22 09:31:54 2011+0800 

Notes added by 'git notes add' 
e80aa7481beda65ae00e35afc4bc4b171f9boebf | 1+ 

1 files changed,1 insertions(+),0 deletions(-) 


从 上 面 的 评注 引用 的 提交 日 志 可 以 看 出 ， 存 在 两 次 提交 ， 并 且 从 
提交 说 明 可 以 看 出 是 使 用 git notes add 命 令 添 加 的 。 至 于 每 次 提交 添加 
的 文件 却 很 让 人 困惑 ， 所 添加 文件 的 文件 名 居然 是 40 位 的 哈 希 值 。 


您 当然 可 以 通过 git checkout-b 命 令 检 出 该 引用 来 研究 其 中 所 包含 
的 文件 ， 不 过 也 可 以 运用 我 们 已 经 学 习 到 的 Git 命 令 直 接 对 其 进行 研 


Ea o 
用 git show 命 令 显 示 目 录 树 。 


$git show-p refs/notes/commits^{tree} 
tree refs/notes/commits^{tree} 
6652a0dce6a5067732c00ef0a220810a7230655e 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 


用 git ls-tree 命 令 查看 文件 大 小 及 对 应 的 blob 对 象 的 SHA1 哈 硕 值 。 


$git ls-tree- refs/notes/commits 
100644 blob 80b1d2...47 6652a0... 
100644 blob e894f2...56 e80aa7... 


文件 名 既然 是 一 个 40 位 的 SHA1 哈 希 值 ， 那 么 文件 名 一 定 有 意义 
通过 下 面 的 命令 可 以 看 到 文件 名 包含 的 40 位 哈 希 值 实际 对 应 于 一 个 提 


AN 
J 


$git cat-file-p 6652a0dce6a5067732c00ef0a220810a7230655e 
tree e33be9e8e7ca5f887c7d5601054f2f510e6744b8 

parent 81993234fc12a325d303eccea20f6fd629412712 

author Jiang Xin<JjiangxinQ@ossxp.com>1291882031+0800 
committer Jiang Xin<jiangxin@ossxp.com>1291882892+0800 
Add Images for git treeview. 

Signed-off-by:Jiang Xin<jiangxin@ossxp.com> 


用 git cat-file 命 令 查 看 该 文件 的 内 容 ， 可 以 看 到 其 内 容 束 是 附加 在 


相应 提交 上 的 评注 。 


$git cat-file-p 
refs/notes/commits:6652a0dce6a5067732c00ef0a220810a7230655e 
Bisect test:Bad commit,for doc/B.txt exists. 


综 上 所 述 ， 评 注 记录 在 一 个 blob 对 象 中 ， 并 且 以 所 评注 对 象 的 


SHA1 哈 希 值 命名 。 因 为 对 象 SHA1 哈 希 值 的 唯一 性 ， 所 以 可 以 将 评注 
都 放 在 同一 个 文件 系统 下 而 不 会 相互 窗 益 。 针 对 这 个 包含 所 有 评注 


的 


` 特殊 的 文件 系统 的 更 改 被 提交 到 一 个 特殊 的 引用 


refs/notes/commits 当 中 。 


[1] 


https://github.com/ossxp-com/gitdemo-commit- 


tree/commit/6652a0dce6a5067732c00ef0a220810a7230655e 


41.5.2 ”评注 相关 命令 


Git 提 供 了 git notes 命 令 对 评注 进行 管理 。 如 采 执 行 git notes list， 
或 者 像 下 面 这 样 不 市 任何 参数 进行 调用 ， 会 显示 和 上 面 git ls-tree 类 似 
的 输出 : 

$git notes 

80b1d249069959ce5d83d52ef7bd0507f774c2b0 
6652a0dce6a5067732c00ef0a220810a7230655e 


e894f2164e77abf0O8d95d9bdad4cd51d00b47845 
e80aa7481beda65ae00e35afc4bc4b171f9boebf 


右边 的 一 列 是 要 评注 的 提交 对 象 ， 而 左边 一 列 是 附加 在 对 应 提 区 
上 的 包含 评注 内 容 的 blob 对 象 。 显 示 附 加 在 某 个 提交 上 的 评注 可 以 使 


用 git notes show 命 令 。 如 下 : 


$git notes Show GAO 
Bisect test:Good commit,for doc/B.txt does not exist. 


注意 上 面 的 命令 中 使 用 G^0 而 非 G， 是 因为 G 古 一 个 里 程 碑 对 和 象 ， 
而 评注 十 建立 在 由 里 程 碑 对 象 所 指向 的 一 个 提交 对 象 上 。 


添加 评注 可 以 使 用 下 面 的 git notes add 和 git notes append 子 命令 : 


法 1:git notes add[-f][-F<file>|-m<msg>|(-c|-c)<object>][< 
object>] 
法 2:git notes append[-F<file>|-m<msg>|(-c|-Cc)<object>][< 
object>] 


用 法 1 是 添加 评注 ， 而 用 法 2 是 在 已 有 评注 后 面 追加 (修改 已 有 评 
注 ) 。 两 者 的 命令 行 格式 和 git commit 非 常 类 似 ， 可 以 用 类 似 写 提交 说 
明 的 方法 写 提 交 评 注 。 如 果 省 略 最 后 一 个 是 <object> 参数 ， 则 意味 着 
向 头 指 针 HEAD 添 加 评注 。 子 命令 git notes add 中 的 参数 -{ 章 味 着 强制 
深 加 ， 会 履 盖 对 象 中 已 有 的 评注 。 


使 用 git notes copy 子 命令 可 以 将 一 个 对 象 的 评注 拷贝 到 另外 一 个 
对 象 上 。 


3 法 :git notes copy[-f](--stdin|<from-object><to-object>) 


修改 评注 可 以 使 用 下 面 的 git notes edit 子 命令 : 


法 :git notes edit[<object>] 


删除 评注 可 以 使 用 的 git notes remote 子 命令 ， 而 git notes prune 则 可 
以 清除 已 经 不 存在 的 对 象 上 的 评注 。 用 法 如 下 : 


法 1:git notes remove[<object>] 
法 2:git notes prune[-n|-v] 


评注 以 文件 形式 保存 在 特殊 的 引用 中 ， 如 采 该 引用 被 共 至 并 且 同 
时 有 多 人 撰写 评注 ， 则 可 能 出 现 该 引用 的 合并 冲突 。 可 以 用 git notes 
merge 命 令 来 解决 合并 冲突 。 评 注 引 用 也 可 以 使 用 其 他 的 引用 名 称 ， 合 


并 其 他 的 评注 引用 也 可 以 使 用 本 命令 。 下 面 是 git notes merge 命 令 的 语 
法 格式 ， 有 具体 操作 请 参见 git help notes 帮 助 。 


法 1:git notes merge[-v|-q][-s<strategy>]<notes_ref>> 用 法 2:git 
notes merge--commit[-v|-q] 
法 3:git notes merge--abort[-v|-q] 


41.5.3 ”评注 相关 配置 


默认 提交 评注 保存 在 引用 refs/notes/commits 中 ， 这 个 默认 的 设置 
可 以 通过 core.notesRef 配 置 变量 来 修改 。 如 需 更 改 ， 要 在 core.notesRef 
配置 变量 中 使 用 引用 的 全 称 而 不 能 使 用 缩写 。 


在 执行 git log 命 令 显 示 提 交 评 注 的 时 候 ， 如 采 配 置 了 
notes.displayRef 配 置 变量 (可 以 使 用 通配符 ， 并 且 可 以 配置 多 个 ) ， 
则 在 显示 提交 评注 时 ， 除 了 会 参考 core.notesRef 设 定 的 引用 (或 默认 的 
refs/notes/commits 引 用 ) 外 ， 还 会 参考 notes.displayRef 指 向 的 引用 (一 


个 或 多 个 ) 来 显示 评注 。 


配置 变量 notes.rewriteRef 用 于 配置 哪个 /哪些 引用 中 的 提交 评注 会 
随 看 提交 的 修改 而 复制 到 新 的 提交 之 上 “。 这 个 配置 变量 可 以 使 用 多 
次 ， 或 者 使 用 通配符 ， 但 该 配置 变量 没有 默认 值 ， 因 此 为 了 使 得 提交 
评注 能 够 随 着 提交 的 修改 (修补 提交 、 变 基 等 ， 而 继续 保持 ， 必 须 对 


该 配置 变量 进行 设 定 。 如 : 


$git config--global notes.rewriteRef refs/notes/* 


还 有 notes.rewrite.amend 和 notes.rewrite.rebase 配 置 变量 可 以 分 别 对 


两 种 提交 修改 模式 (amend 和 和 rebase) 是 否 启 用 评注 复制 进行 设置 ， 默 


认 启 用 。 配 置 变量 notes.rewriteMode 默 认 设置 为 concatenate， 即 提交 评 
注 复制 到 修改 后 的 提交 时 ， 如 果 已 有 评注 则 对 评注 进行 追加 操作 。 


第 9 篇 ” 附 条 
附录 A Git 命令 索引 


每 一 个 Git 子 命令 都 和 特定 目录 下 的 一 个 名 为 git-< cmd> 的 文件 相 
对 应 ， 也 束 古 在 这 个 特定 目录 下 存在 的 名 为 git-<cmd> 的 可 执行 文件 
机 可 以 用 命令 git< cmd> 来 执行 。 可 以 用 下 面 的 命令 查看 这 个 特定 目 
了 永 的 位 置 : 


$git--exec-path 
/usr/lib/git-core/ 


在 这 个 目 孙 下 有 150 多 个 可 执行 文件 ， 也 束 是 说 Git 有 非常 多 的 子 
命令 。 在 如 此 众多 的 子 命令 中 ， 彰 用 的 实际 上 只 有 不 到 1/3， 其 余 的 命 
令 或 者 作为 底层 命令 供 其 他 命令 及 脚本 调用 ， 或 者 用 于 某 些 生僻 场 
合 ， 或 者 已 经 过 时 但 出 于 兼容 性 的 考虑 而 仍然 保留 。 下 面 的 表格 分 门 
别 类 地 对 所 有 的 Git 命 令 进行 概要 性 的 介绍 ， 凡 是 在 本 书 出 现 过 的 命令 
将 标 出 其 所 在 的 章节 号 和 页 码 。 


A.1 第 用 的 Git 命 令 


命令 
git add 

git add--interactive 
git apply 

git am 

git annotate 
git archive 

git bisect 

git blame 

git branch 

git cat-file 

git checkout 
git cherry-pick 
git citool 

git cican 


sit clone 


TD 
EE EE 

硬件 交工 
EC | 这 和 

ET 
| 
EE 版 本 库 对 象 研究 工具 

检 出 到 工作 区 、 切 换 或 创建 分 支 
162 提交 拣选 
Bi | 图 形 化 提交 ， 相当 于 gitgui 命 令 
清除 工作 区 未 跟踪 文件 


命令 
git commit 
git config 

git describe 
git di 在 

git difftool 
git fctch 

git format-patch 
git grep 

git gui 

git help 

git init 

git init-db 
git log 

git merge 

git mergctool 
git my 

git pull 

git push 


git rebase 


〈 续 ) 
简要 说 明 


60: 65 ;8i 提交 
一 |- | 调用 图 形 化 差异 比较 工具 
获取 远程 版 本 库 的 提交 
创建 闻 件 格式 的 补丁 文件 。 参 见 gtam 命令 
文件 内 容 搜索 定位 工具 
mw TITYTTTT 
2 图 形 化 冲突 解决 

180 | 拉 同 远程 版 本 库 的 提交 

13.1 EE 推送 至 远程 版 本 库 


分 支 变相 


git reflog 

git remote 
git repo-config 
git resct 

git rev-parse 
git revert 
git rm 

git show 

git stage 

git stash 

git status 


git tag 


[1] 其 中 有 几 个 脚本 不 能 单独 运行 ， 而 是 被 其 他 脚本 包含 
应 的 函数 库 ， 如 git-sh-setup。 


II 
rm cr 将 各 种 引用 表示 法 转换 为 哈 希 值 等 
ET 

显示 工作 区 文件 状态 

TI 


， 用 于 提供 相 


A.2 对 象 库 操 作 相 关 价 


全 
必 


git commit-tree 12.4 175 从 树 对 象 创建 提交 

Bit haa object 12.4 176 从 标准 输入 或 文件 计算 险 希 值 或 创建 对 象 
| 显示 工作 区 和 暂 存 区 文件 

HE 53 显示 树 对 象 包含 的 文件 

二 Fi 一 | | 并 到 杭 必 输入 创造 一 个 里 程 碑 对 象 
Bemis 一 | 一 | 该 耻 标准 输入 创建 一 个 树 对 旬 

git read-tree 24.2 349 读 取 树 对 象 到 暂 存 区 

iruplate hdex 工作 区 内 容 注 册 到 暂 存 区 及 暂 存 区 管理 
二 pw 和 -| 创建 临时 文件 包含 指定 blob 的 内 容 


1 
人 


从 暂 存 区 创建 一 个 树 对 象 


git write-tree 


A.3 引用 操作 相关 命令 


命令 
git check-ref-format 
git for-cach-ref 
git ls-remote 
git name-rev 
git peek-remote 
git rev-list 
git show-branch 
git show-ref 
git symbolic-ref 
git updatc-ref 


git verify-tag 


检查 引用 名 称 是 否 符合 规范 
-| 引用 迭代 器 ， 用 于 shell 编程 
4 js6 | 呈 示 远程 版 本 库 的 引用 
一 | 一 | 曙 款 9 支 列表 及 拓 补 关系 
一 |= | 呈 示 或 设置 符号 引用 


A.4 版 本 库 管理 相关 命令 


ne | WR | | a 
gitcount-objects | 一 | 一 | 品 示 松 散 对 象 的 数量 和 磁盘 占用 

git filter-branch 版 本 库 重 构 

git fsck 对 象 库 完整 性 检查 

git 人 ck-objcets 一 =- | 同义词 ， 等 同 于 git fsck 

git ge 版 本 库存 储 优化 

git index-pack 一 |- | 从 打包 文件 创建 对 应 的 索引 文件 

git lost-found 一 |- | 过 时 ， 请 使 用 git fsck --lost-found 命令 
gitpack-objeets | 一 | 一 | 从 标准 输入 读 人 对 象 ID， 打 包 到 文件 

git pack-redundant 一 = 查找 多 余 的 pack 文件 

git pack-refs 1 [ss | 将 引用 打包 到 .gitipacked-refs 文件 中 

git prune 从 对 象 库 删 除 过 期 对 象 

gitprune-packed | 一 | 一 | 林 已 经 打包 的 松散 对 象 种 除 

git relink 一 | 一 | 为 本 地 版 本 库 中 相同 的 对 象 建 立 硕 连 接 

git repack 将 版 本 库 未 打包 的 松 斤 对 象 打包 
gitshow-index |141 sg | 读 取 包 的 索引 文件 ,显示 打包 文件 中 的 内 容 
gitunpack-objects | 一 | 一 | 从 打包 文件 释放 文件 

git verify-pack 一 |- | 校 验 对 和 象 库 打包 文件 


A.5 ”数据 传输 相关 命令 


命令 相关 欠 市 


执行 git fetch 或 git pull 命令 时 在 本 地 执行 此 命令 ， 用 于 
git fetch-pack 15.1 201 亿 其 他 酸 本 亩 获取 马 失 的 对 象 


执行 git push 命令 时 在 远程 执行 的 命令 ， 用 于 接受 推送 的 


简要 说 明 


git reccive-pack 15.1 
本 


201 

201 执行 git push 命令 时 在 本 地 执行 的 命令 ， 用 于 向 共 他 版 本 
外 库 推 送 数 据 

201 


git send-pack 


执行 git archive --remote 命令 基于 还 程 版 本 库 创建 归档 
上 时， 远程 版 本 库 执行 此 命令 传送 归档 


git upload-archive 


执行 git fetch 或 git pull 命令 时 在 远程 执行 紫 命 令 ， 将 对 
象 打包 、 上 传 


15.1 


A.6 邮件 相关 命令 


命令 
git imap-send 
git mailinfo 
git mailsplit 
git requcst-pull 


git send-email 


一 | 一 人 导出 提交 说 明和 补丁 
一 | 一 | 将 mbox 或 Maildir 格 式 邮箱 中 的 邮件 逐一 提取 为 文件 
创建 包含 棍 交 间 差 异 和 执行 PULL 视 作 地 址 的 信息 


A.7 协议 相关 命令 


命令 
git dacmon 
git http-backend 
git instaweb 
git shell 
git updatc-server-info 
git http-feteh 
git http-push 
git remote-ext 
git remote-{fd 
git remote-ttip 
git remotc-ftps 
git remote-http 
git remote-https 


git remote-testgit 


me 实现 HTTP 协议 的 CGI 程序 ， 支 持 智 能 HTTP 协议 
到 时 启动 浏览 器 通过 gitweb 浏览 当前 版 本 库 


受 限制 的 shell， 提 供 仅 执 行 Git 命令 的 SSH 访问 


更 新 号 协议 需要 的 辅助 文件 


通过 HTTP 协议 获取 版 本 库 


27. 


记 


由 Git 命 令 调用 ， 通 过 外 部 命令 提供 扩展 协议 支持 


由 Git 命令 调 用 ， 使 用 文件 描述 符 作 为 协议 接口 


S| 

一 |- | 自 Git 命 令 调用 ,提供 对 FTP 协议 的 支持 
一 | | 由 Git 命 令 两 用 提供 对 FTPS 协议 的 支持 
一 | | 自 Git 命 令 调用 ,提供 对 HTTP 协议 的 支持 
一 |- | 自 Git 命 令 届 用， 提供 对 HTTPS 协议 的 支持 
一 | 一 | 坎 议 扩展 示例 即 本 


A.8 ”版 本 库 转 换 和 交互 相关 命令 


Eit archimport -| 导 人 Arch 版 本 库 到 Git 

git bundle 一 | | 提交 打包 和 解 包 ， 以便 在 不 同 版 本 库 间 传 递 
Bikevesxporioomit |- | 将 Git 的 一 个 提交 作为 一 个 CVS 检 出 

Bt ovaimpot -|- | 导 人 CVS 版 本 库 到 Git， 或 者 使 用 cvs2git 

Elbevaerver 一 =- Git 的 CVS 协议 模拟 器 ， 可 供 CVS 命令 访 间 Git 版 本 库 
git fast-export 一 | 一 | 将要 交 导 出 为 gifastimport 格式 

git fast-import 其 他 版 本 库 迁 移 至 Git 的 通用 工具 

En Git 作为 前 端 操作 Subversion 


A.9 合并 相关 的 辅助 


命令 
git merge-basc 
git mergc-file 
git mergc-indcx 
git mergc-octopus 
git mergc-onc-file 
git mergc-ours 
git mergc-recursive 
git meruc-resolve 
git merge-subtree 
git merge-tree 
git fmt-merge-msg 


git rerere 


相关 党 节 
11.4.2 


于 
心 


简要 通明 
供 其 他 脚本 调用 ， 找 到 本 个 或 多 个 提交 最 近 的 共同 祖先 
针对 文件 的 两 个 不 同 版 本 执行 三 向 文件 合并 
对 index 中 的 钟 突 文 件 调 用 指定 的 冲突 解决 工具 
全 并 两 个 以 上 的 分 支 。 人 参见 git merge 的 octopus 合并 策略 


由 git merge-index 调用 的 标准 辅助 程序 


合并 使 用 本 地 版 本 ， 描 弃 他 人 版 本 。 众 见 git merge 的 ours 
合并 策略 

针对 两 个 分 支 的 三 向 合 并 。 参 见 git merge 的 recursive 合 
并 策略 

针对 两 个 分 支 的 三 向 合并 。 奉 见 git merge 的 resolve 合并 
筑 路 

子 树 合 并 ， 参 见 git merge 的 subtree 合并 策 酷 


显 式 三 各 合并 结果 ， 不 改变 暂 存 区 
供 执行 合并 操作 的 脚本 调用 ， 用 于 创建 一 个 合并 提交 说 明 
重用 所 记录 的 冲突 解决 方案 


A.10 杂项 


命令 
git bisect--helper 
git check-attr 
git checkout-index 
git cherry 
git diff-files 
git diff-index 
git dift-tree 
git difftool--helper 
git get-tar-commit-id 
git gui--askpass 
git notes 
git patch-id 
git quiltimport 
git replace 
git shortlog 
git stripspace 
git submodule 
git tar-tree 
git var 
git web--browse 


git whatchanged 
git-mergctool--lib 


git-parsc-remote 


git-sh-sctup 


相关 章节 简要 说 明 

由 git bisect 命令 调用 ， 确 认 二 分 查找 进度 
显示 某 个 文件 是 否 设置 了 某 个 属性 

从 暂 存 区 拷贝 文件 至 工作 区 

查找 没有 合并 到 上 游 的 提交 

比较 暂 存 区 和 工作 区 ， 相 当 于 git diff --raw 
比较 暂 存 区 和 和 夏 本 库 ， 相 当 于 git diff --cached --ravw 
比较 两 个 树 对 象 ， 相 当 于 git dif--rawAB 
由 sit difftoal 命令 调用 ， 默 认 要 使 用 的 差异 比较 工具 
从 git archive 创建 的 tar 包 中 提取 复 交 名 
命令 git gui 的 获取 用 户口 令 输 入 界面 

提交 评论 管理 

补丁 过 赴 行 号 和 空白 字符 后 生成 补丁 唯一 ID 
将 Quilt 补 于 列表 应 用 到 当前 分 支 

提交 替换 

对 git log 的 汇总 输出 ， 适 人 台 于 产品 发 布 说 明 
删除 空 行 ， 供 其 他 竹本 调用 

于 模 组 管理 

过 上 时 命令 ， 请 使 用 git archive 

显示 Git 环境 变量 

启动 浏览 器 以 查看 目录 或 文件 

显示 酌 交 历史 及 每 次 提交 的 改动 


包含 于 其 他 层 本 中 ,提供 合 并 / 菱 异 比较 工具 的 
选择 和 搞 行 


包含 于 其 他 妓 本 中 ， 提 供 操作 远程 版 本 库 的 函 救 
包含 于 其 他 丢 本 中 ,提供 shcll 编程 的 函数 库 


41.1.2 


18.4.4 


个 


SS 


by ss 
一 人 
a hp 
Fw 
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附 隶 B ”Git 与 CVS 面 对 面 


B.1 面对面 访谈 也 


Git， 我 的 提交 是 原子 提交 。 每 次 提交 都 对 应 于 一 个 目录 树 ( 树 对 
象 ) 。 因 为 我 的 提交 ID 是 对 目录 树 及 相关 的 提交 信息 建立 的 一 个 
SHA1 哈 布 值 ， 所 以 可 以 保证 数据 的 完整 性 。 


CVS: 我 承认 这 是 我 的 软肋 ， 一 次 错误 或 冲突 的 提交 会 导致 部 分 
数据 被 提交 ， 而 部 分 数据 没有 提交 ， 版 本 库 的 完整 性 会 被 破坏 ， 所 以 
人 们 才 设 计 出 来 Subversion (SVN) 来 取代 我 。 


Git: 我 的 分 文 和 里 程 碑 管理 非常 快捷 。 因 为 我 的 分 文 和 里 程 碑 束 
是 一 个 记录 提交 ID 的 40 字 节 的 文件 ， 你 的 呢 ? 


CVS: 你 怎么 义 提 到 别人 的 痛处 了 ! 我 的 分 文 和 里 程 碑 创建 速度 
还 是 很 快 的 ，.……. Ne 如 果 在 版 本 库 中 只 有 几 个 文件 的 话 。 当 然 
如 果 版 本 库 中 的 文件 很 多 ,创建 分 支 和 里 程 碑 束 需要 花费 很 长 的 时 
间 。 有 些 人 对 此 和 忍 无 可 息 ， 于 是 设计 出 SVN 来 取代 我 。 


Git 其 实 我 不 用 里 程 碑 都 没有 关系 ， 因 为 每 个 提交 有 D 殊 对 应 于 唯 


一 的 一 个 提交 状态 。 


CVS: 这 也 是 我 做 不 到 的 。 我 没有 全 局 版 本 号 的 概念 ， 每 个 文件 
都 通过 单独 的 版 本 号 记录 其 变更 历史 ， 所 以 人 们 在 使 用 我 的 时 候 必须 
经 常用 里 程 碑 (tag) 对 我 的 状态 进行 标识 。 还 需要 提醒 一 名 的 是 ， 如 
果 版 本 库 中 的 文件 太 多 ， 创 建 里 程 牧 是 很 耗 时 的 ， 因 为 要 逐一 打开 每 
个 版 本 库 中 的 文件 ， 并 在 其 中 记录 里 程 碑 和 文件 版 本 的 关联 。 


Git: 我 的 工作 区 很 干净 。 只 在 工作 区 的 根 目录 下 有 一 个 .git 目 
隶 ， 此 外 再 无 其 他 辅助 目录 或 文件 。 


CVS: 我 要 在 工作 区 的 每 一 个 目录 下 都 放置 一 个 CVS 目 录 ， 这 个 
目录 下 有 个 Entries 文 件 很 重要 ， 记 录 了 对 应 工作 区 文件 的 检 出 版 本 及 
时 间 惟 等 信息 。 这 样 做 的 好 处 是 可 以 将 工作 区 移动 到 任何 其 他 磁盘 和 
目录 ， 而 豪 不 影响 使 用 ， 甚 至 我 可 以 将 工作 区 的 一 个 子 目录 拿 出 来 ， 
作为 独立 的 工作 区 。 


Git: 我 也 可 以 将 工作 区 移动 到 其 他 磁 列 ， 但 是 要 保证 工作 区 下 
的 .git 目 录 和 工作 区 一 同 移动 。 不 可 以 只 移动 工作 区 下 的 一 个 目录 到 其 
他 磁 副 或 目录 ， 那 样 的 话 移出 的 目录 束 不 能 工作 了 。 


Git: 我 的 网 络 传输 效率 很 高 。 在 和 其 他 版 本 库 交 互 时 ， 对 方 会 告 
诉 我 他 有 什么 ， 我 也 知道 我 有 什么 ， 因 为 只 传输 缺失 对 象 的 打包 文 
件 ， 所 以 效率 很 高 而 且 能 够 显示 传输 进度 。 


CVS: 这 一 点 我 不 行 。 因 为 我 本 地 没有 文件 做 对 照 ， 所 以 我 在 传 
输 的 时 候 不 可 能 做 到 增 量 传输 。 


Git: 我 甚至 可 以 不 需要 网 络 ， 因 为 我 在 本 地 拥有 完整 的 版 本 库 ， 
几乎 所 有 的 操作 都 在 本 地 完成 。 


CVS: 我 的 操作 处 处 需要 网 络 ， 如 果 有 版 本 库 在 网 络 中 的 其 他 服务 
郁 上 ， 而 且 网 速 又 比较 慢 ， 那 么 查看 日 志 或 历史 版 本 都 需要 等 很 长 时 
间 。 


CVS: 你 怎么 没有 更 新 (update) 命令 ? 还 有 你 为 什么 老 是 要 执 
行 检 出 命令 (checkout) ? 对 我 而 言 ， 检 出 命令 只 在 工作 区 创建 时 一 
次 性 完成 。 


人 和 人、 
Hp 


Git， 你 的 检 出 命令 (checkout) 是 从 远程 版 本 库 服务 句 获 取 数 据 
来 完成 本 地 工作 区 的 创建 ， 版 本 库 仍然 位 于 远程 服务 右上 。 你 的 更 新 
(update) 命令 执行 得 很 慢 ， 对 吗 ? 之 所 以 你 需要 执行 更 新 命令 是 因 
为 你 的 版 本 库 在 远程 啊 。 别 二 了 我 的 版 本 库 是 在 本 地 ， 本 地 版 本 库 会 
随 着 我 在 本 地 工作 区 中 的 操作 (如 提交 ) 而 更 新 。 我 的 检 出 
(checkout) 操作 是 将 本 地 版 本 库 的 数据 检 出 到 本 地 工作 区 ， 用 于 恢 
复 本 地 丢失 或 错误 改动 的 文件 ， 也 用 于 切换 不 同 的 分 文 。 我 也 有 一 个 
和 你 的 更 新 (update) 操作 类 似 的 、 比 较 耗 时 的 网 络 操作 命令 ，git 
fetch 或 git pul， 这 两 个 操作 是 从 别人 的 版 本 库 获取 他 人 的 改动 。 一 般 


使 用 我 (Git) 做 团队 协作 的 时 候 ， 会 部 署 一 个 集中 共享 的 版 本 库 ， 我 
就 用 这 两 个 命令 (git fetch 或 git pull) 从 共享 的 版 本 库 执 行 拉 回 操作 。 
也 许 你 (CVS) 会 觉得 git fetch 或 git pul 和 你 的 cvs update 命 令 更 像 吧 。 
至 于 你 的 检 出 命令 (cvs checkout) ， 实 际 上 和 我 的 克隆 命令 (git 
clone) 很 相似 ， 只 不 过 我 的 克隆 命令 不 但 创建 了 本 地 工作 区 ， 而 且 在 
本 地 还 复制 了 和 远程 版 本 库 一 样 的 本 地 版 本 库 。 


CVS: 为 什么 你 的 检 入 (commit) 命令 执行 得 那么 快 ? 


Git: 是 的 ， 我 的 检 入 命令 飞 一 般 束 执行 完了 ， 这 也 是 因为 版 本 库 
就 在 本 地 。 也 许 你 (CVS) 会 觉得 我 的 推送 命令 (git push) 和 你 的 检 
入 命令 (cvs commit) 更 相像 ， 其 实 这 是 一 个 误会 。 如 采 我 不 做 本 地 
提交 ， 是 没有 东西 可 以 推送 (git push) 的 。 你 (CVS) 每 一 次 提交 都 
要 和 版 本 库 进 行 网 络 通信 ， 而 我 可 以 在 本 地 版 本 库 进行 多 次 提交 ， 直 
到 我 的 主人 想 喝 咖啡 了 才 执 行 一 次 git push， 将 我 本 地 版 本 库 中 的 新 提 
交 推 送 给 远程 版 本 库 。 


CVS: 我 每 个 文件 都 一 个 独立 的 版 本 号 ， 你 有 吗 ? 


Git: 每 个 文件 一 个 版 本 号 ? 这 有 什么 值得 态 糠 的? 我 昕 说 你 最 早 
征用 脚本 对 RCS 系 统 进行 封 厂 实 现 的 ， 所 以 你 的 每 个 文件 都 有 一 个 独 
立 的 版 本 控制 ， 这 让 你 变 得 很 和 零碎。 我 听 说 某 些 商业 版 本 控制 系统 


征 这 样 ， 真 糟糕 。 我 的 每 次 提交 都 有 一 个 全 球 唯一 的 版 本 号 ， 不 但 在 
本 地 版 本 库 中 是 唯一 的 ， 和 其 他 人 的 版 本 库 也 不 会 有 冲突 。 


CVS: 我 能 一 次 检 出 一 个 日 录 ， 你 好 像 不 能 吧 ? 


Git: 所 以 我 有 子 模 组 ， 以 及 repo 等 第 三 方 工 具 ， 可 以 帮助 我 把 一 
个 大 的 版 本 库 拆 成 多 个 版 本 库 组 合 来 使 用 啊 。 而 且 我 还 有 稀 芒 检 出 的 
功能 ， 只 不 过 很 少 有 人 用 到 妥 了 。 


CVS: 我 能 添加 空 日 录 ， 你 好 像 不 能 吧 ? 


Git: 是 的 ， 我 现在 还 不 能 记录 空 目 未 。 但 是 用 户 可 以 在 空 目 未 下 
创建 一 个 隐 含 文件 ， 并 将 该 隐 含 文件 添加 到 版 本 库 中 ， 这 束 实 现 了 空 
目录 的 添加 功能 。 你 ，CVS， 目 隶 管理 钙 你 的 软肋 ， 你 很 难 实现 目 孙 
的 重 命名 ， 而 目录 重 命名 对 我 来 说 却 是 小 染 一 碟 。 


B.2 _Git 和 CVS 命 令 对 有 照 


比较 项 目 CVS 命令 GIT 命令 


:pserver-useria host:/path/to/cvsroot git-//hostpath/to/repos. git 


ssh://useri@host/path/to/rcpos.git 
URL I uscr(whost-path/to/repos. git 
导入 数据 Cys -d <url> import -m ... git clone; git add .; git commit 
版 本 库 检 出 cvs -d <url> chcckout [-d <path>] <module> git clone <url> <path> 
版 本 库 分 支 检 出 evs -d <url> checkout -r <branch> <modulec> git clonc -b <branch> <url> 
工作 区 更 新 i 
更 新 至 历 忠 版 本 git checkout <commit> 
更 新 到 指定 日 期 git checkout HEAD@' {<date>}' 
切换 至 里 程 下 ot a 
切换 至 分 支 git checkout <branch> 
移动 文件 my <old> <new>: evs rm <old>. evs add <new> git my <old> <new> 
git di 
工作 区 差异 比较 evs diff -u git diff --cached 
git diff HEAD 
版 本 间 差 异 比较 evs diff -u -r <revl> -r <rev2> <path> Ss SO 
村 交 cvs commit -m "<msg>" git commit -a -m "<msg>" ; git Push 


ep git tag 
示 果 程 i 5 5 5 -V 
显示 里 程 析 /分支 CYS Status -v git branch 
i 


l Wo i git tag [-m "<msg>"] <tagname> 
创建 里 程 析 evs tag [-r <rev>] <tagname> . [<commjt>] 


git branch <branch> <commit> 


创建 分 支 cvs rtag -b -r <rev> -b <branch> <module> 
git checkout -b <branch> <commit> 


铀 除 分 支 cysrtag -d <branch> git branch -d <branch> 


git archive -0 <output.tar> <tag> 
<path> 

git archive -9 <output.tar> 
—rcmotc=<url> <tag> <path> 


导出 项 目 文 件 evs -d <url> export -r <tag> <module> 


分 支 合 并 cvs update [-] <start>] -] <end>; cvs commit git mmerge <branch> 


显示 文件 列表 


cvs -d <url> rls -r <revy> git ls-tree <commit> 


更 改 扣 交 说 明 cvs admin -m <rev>:<msg> <path> git commit --amend 


撤销 提交 cvs admin -0 <range> <path> git resct| --soft | 一 hard ] HEAD^ 
杂项 参数 -kb 设置 二 进 制 模式 -text 属性 


参数 -kv 开启 关键 字 扩 展 export-subst 昼 性 


附 隶 C ”Git 与 SYN 面 对 面 


C.1 面对面 访谈 采 


Git: 我 的 提交 历史 本 号 就 是 一 幅 美丽 的 图 画 一 -DAG (Directed 
Acylic Graph， 有 向 无 环 图 ) ， 可 以 看 到 各 个 分 支 之 间 的 合并 关系 。 而 
你 SVN， 你 的 提交 历史 怎么 是 一 条 直线 呢 ? 要 是 在 重症 监护 室 看 到 
你 ， 还 以 为 你 挂 掉 了 呢 ? 


SVN: 我 觉得 插 好 ， 人 至 少 我 每 次 提交 会 有 一 个 全 局 的 版 本 号 ， 而 
且 我 的 版 本 号 是 递增 的 。 你 的 版 本 号 不 是 递增 的 吧 ? 


Git: 你 说 的 对 ， 我 的 版 本 号 不 是 一 个 简单 递增 的 数字 ， 而 是 一 个 
长 达 40 位 的 十 六 进 制 数字 〈 哈 希 值 ) ， 但 是 可 以 使 用 短 格式 ， 只 要 不 
冲突 。 虽 然 我 的 提交 编号 看 起 来 似乎 是 无 序 的 ， 但 实际 上 我 的 每 一 个 
提交 都 记录 了 父 提 区 甚至 是 双亲 或 多 杀 提 交 ， 因 此 可 以 很 容易 地 从 任 
意 一 个 提交 开始 建立 一 条 指 癌 历史 提交 的 跟 踩 链 。 


SVN: 是 啊 ， 我 的 一 个 提交 和 前 一 个 提交 有 时 根本 没有 关系 ， 例 
如 一 个 提交 是 发 生 在 主线 /tunk 中 的 ， 下 一 个 提交 可 能 就 发 生 
在 /branches/1.3.X 分 文中 。 你 要 知道 ， 要 想 画 出 一 个 像 你 那样 的 分 文 
图 ， 我 要 做 多 少 工作 吗 ? 我 不 容易 呀 。 


Git: 我 一 直 很 奇怪 ， 你 的 分 文 和 里 程 碑 怎么 看 起 来 和 目录 一 样 ? 
我 的 分 文 和 里 程 碑 名 字 昌 然 看 起 来 像 是 目 永 ， 但 实际 上 和 工作 区 的 目 
孙 完 全 没有 关系 ， 只 是 对 提交 ID 的 一 个 记号 而 已 。 


SVN: 我 一 开始 觉得 我 用 轻 量 级 找 贝 的 方式 实现 分 支 和 里 程 碑 会 
很 酷 ， 也 很 快 。 但 是 我 发 现 很 多 人 在 使 用 我 的 时 候 ， 直 接 在 版 本 库 的 
根 目 永 下 创建 文件 而 不 是 把 文件 创建 在 /trunk 目 未 下 ， 这 吏 导 致 这 些 人 
无 法 再 创建 分 文 和 里 程 碑 了 ， 因 为 无 法 将 根 目录 拷贝 到 子 目 录 呀 ! 


Git: 那么 你 是 如 何 对 分 文 合 并 进行 跟 踩 的 呢 ? 因为 我 有 DAG 的 捍 
交 天 系 图 ， 很 容易 天 可 以 看 出 分 文 之 间 的 合并 历史 ， 但 是 你 是 怎么 做 
到 的 呢 ? 


SVN: 我 用 了 一 点 小 技巧 ， 通 过 属性 (svn:mergeinfo) 记录 了 合 
并 的 分 文 名 和 版 本 范围 ， 这 样 再 合并 的 时 候 ， 我 会 根据 相关 属性 确定 
征 否 要 合并 。 但 是 如 果 经 党 在 子 目 永 下 合并 ， 会 有 太 多 的 
svn:mergeinfo 属 性 等 竺 我 检查 ， 我 会 很 困扰 。 还 有 我 的 这 个 功能 是 在 
1.5 以 后 的 版 本 才 提供 的 ， 因 此 老 版 本 会 破坏 这 个 机 制 。 


SVN: 对 了 ， 我 的 属性 能 干 很 多 事 哦 ， 我 甚至 可 以 把 我 的 照片 作 
为 属性 附加 在 文件 上 。 


Git， 这 所 我 承认 ， 你 的 属性 非 第 强大 。 其 实 我 也 文 持 属性 ， 只 不 
过 实现 方式 不 同村 了 。 而 且 我 可 以 通过 评注 的 方式 为 任意 对 象 〈 提 


交 、 文 件 、 里 程 碑 等 ) 添加 评注 ， 也 可 以 实现 把 照片 作为 评注 附加 在 
文件 上 ， 可 是 这 个 功能 有 什么 实际 用 处 呢 ? 


SVN: 我 有 轻 量 级 拷贝 ， 而 我 的 分 文 和 里 程 碑 就 是 通过 拷贝 实现 
的 ， 很 强大 哦 。 


Git: 我 根本 束 不 需要 轻 量 级 找 贝 ， 因 为 我 对 文件 的 保存 和 文件 的 
路 径 无 天 ， 我 只 关心 内 容 。 所 以 相同 内 容 的 文件 无 论 它 们 的 文件 名 相 
差 有 和 多大， 在 我 这 里 只 保存 一 份 。 而 你 SVN， 如 采用 户 志 了 用 轻 量 级 
拷贝 ， 版 本 库 是 不 是 负担 很 重 啊 。 


SVN: 听 说 你 不 能 针对 目录 授权 ， 这 可 是 我 的 强项 ， 所 以 公司 无 
论 大 小 都 在 用 我 作为 版 本 控制 系统 。 


Git: 不 要 说 你 的 授权 了 ， 人 简直 是 一 团 糟 。 昌 然 这 本 书 的 作者 为 你 
写 了 一 个 图 形 化 的 授权 管理 工具 英 ， 对 你 的 授权 会 有 所 改善 ， 但 是 你 
糟糕 的 分 文 和 里 程 碑 的 实现 ， 会 导致 授权 在 新 的 分 文 和 里 程 碑 中 叉 要 
逐一 进行 设置 ， 工 作 量 其 大 无 比 。 虽然 沁 路 径 授 权 古 一 个 解决 方案 ， 
但 是 官方 并 没有 提供 啊 。 


Git: 说 说 我 的 授权 吧 。 如 采 你 认真 地 读 过 本 书 服务 右 以 设 的 相关 
草 市 ， 你 会 为 我 能 够 提供 按照 分 支 ， 以 及 按照 路 径 进行 写 操作 授权 的 
功能 而 击 掌 叫好 的 。 当 然 我 的 读 操 作 授 权 还 不 能 做 到 很 精细 ， 但 是 可 


以 将 版 本 库 拆 分 成 春 干 个 小 的 版 本 库 啊 ， 再 参照 本 书 介绍 的 各 种 多 版 
本 库 协 同 模式 ， 也 会 找到 一 个 适合 的 解决 方案 的 啊 。 


Git: 我 的 工作 区 很 干净 。 只 在 工作 区 的 根 目录 下 有 一 个 .git 目 
孙 ， 此 外 再 无 其 他 。 


SVN: 我 要 在 工作 区 的 每 一 个 目录 下 都 放置 一 个 .swn 目 杂 ， 这 个 
目 了 在 Linux 下 可 古 隐 藏 的 哦 。 这 个 目 邓 下 不 但 有 了 跟 踩 工作 区 文件 状态 
的 跟踪 文件 ， 而 且 还 有 每 一 个 文件 的 原始 拷贝 呢 。 这 样 有 的 操作 束 可 
以 脱离 网 络 执行 了 ， 例 如 : 差异 比较 、 工 作 区 文件 的 回 滚 。 


Git， 咽 ， 你 要 是 像 我 一 样 能 再 多 保存 一 点 内 容 (整个 版 本 库 ) 就 
更 好 了 。 像 你 这 样 在 每 个 工作 区 子 目 未 下 都 有 一 个 .svn 目 未 ， 而 且 每 
个 .svn 目 孙 下 都 有 文件 的 原始 拷贝 ， 在 进行 内 容 搜索 的 时 候 会 搜索 出 
两 份 吧 ， 太 干扰 了 。 而 且 你 这 么 做 和 CVS 一 样 有 安全 风险 ， 造 成 本 地 
文件 名 的 信息 泄 调 ， 千 万 不 要 在 Web 服 务 郁 上 用 SVN 检 出 哦 。 


Git: 我 的 操作 可 以 不 需要 网 络 。 因 为 我 在 本 地 拥有 完整 的 版 本 
库 ， 儿 乎 所 有 操作 都 是 在 本 地 完成 的 。 


SVN: 正如 前 面 说 到 的 ， 我 有 部 分 命令 可 以 不 需要 网 络 ， 但 是 其 
他 绝 大 多 数 命令 还 是 要 依赖 网 络 的 。 


SVN， 你 怎么 没有 更 新 (update) 命令 啊 ? 还 有 你 为 什么 老 是 要 
执行 检 出 命令 (checkout) ? 对 我 而 言 ， 检 出 命令 只 在 工作 区 创建 时 
一 次 性 完成 。 


Git， 你 的 这 个 问题 怎么 和 CVS 问 的 一 样 。 你 的 更 新 (update) 命 
令 执行 的 很 慢 ， 对 吧 ? 首先 你 要 用 检 出 命令 (checkout) 建立 工作 
区 ， 然 后 你 要 经 常 执行 更 新 (update) 命令 进行 更 新 ， 否 则 很 容易 造 
成 你 的 更 改 和 他 人 的 更 改 发 生 冲突 。 


Git: 之 所 以 你 需要 更 新 十 因为 你 的 版 本 库 在 远程 啊 。 别 起 了 我 的 
版 本 库 是 在 本 地 ， 本 地 的 版 本 库 会 随 着 我 在 本 地 工作 区 中 的 操作 (如 
提交 ) 而 更 新 。 我 的 检 出 (checkout) 操作 一 般 用 于 用 户 切换 分 支 ， 
或 者 从 本 地 版 本 库 检 出 丢失 的 文件 或 覆盖 本 地 错误 改动 的 文件 。 如 果 
我 没 记 错 的 话 ， 你 切换 分 文 用 的 是 svn switch 命 令 对 么 ? 


Git: 实际 上 我 也 有 一 个 比较 耗 时 的 网 络 操作 命令 : git fetch 或 git 
pull， 这 两 个 操作 是 从 远程 版 本 库 获 取 他 人 的 改动 。 一 般 使 用 我 
(Git) 做 团队 协作 的 时 候 ， 会 部 署 一 个 集中 共享 的 版 本 库 ， 我 就 从 这 
个 共享 的 版 本 库 执 行 拉 回 操 作 。 也 许 你 (SVN) 会 觉得 git fetch 或 git 
pul 和 你 的 svn update 命 令 更 像 吧 。 至 于 你 的 检 出 命令 (svn 
checkout) ， 实 际 上 和 我 的 克隆 命令 (git clone) 很 相似 ， 只 不 过 我 的 
克隆 命令 不 但 创建 了 本 地 工作 区 ， 而 且 在 本 地 还 复制 了 和 远程 版 本 库 
一 样 的 本 地 版 本 库 。 


SVN: 为 什么 你 的 检 入 (commit) 命令 执行 得 那么 快 ? 


Git: 是 的 ， 我 的 检 入 命令 飞 一 般 束 执行 完了 ， 这 也 是 因为 我 的 版 
本 库 就 在 本 地 。 也 许 你 (SVN) 会 觉得 我 的 推送 命令 (git push) 和 你 
的 检 入 命令 (svn commit) 更 相像 ， 其 实 这 是 一 个 误会 。 如 果 我 不 做 
本 地 提交 ， 是 不 能 通过 推送 命令 (git push) 将 我 的 本 地 提交 共享 给 
(推送 给 ) 其 他 版 本 库 的 。 你 (SVN) 每 一 次 的 提交 都 要 和 版 本 库 进 
行 网 络 通信 ， 而 我 可 以 在 本 地 版 本 库 进 行 多 次 提交 ， 直 到 我 的 主人 想 
喝 咖 啡 了 才 执 行 一 次 git push， 将 我 本 地 版 本 库 中 的 新 提交 推送 给 远程 
版 本 库 。 


SVN: 我 能 一 次 检 出 一 个 目录 ， 你 好 像 不 能 吧 ? 


Git: 所 以 我 有 子 模 组 ， 以 及 repo 等 第 三 方 工 具 ， 可 以 帮助 我 把 一 
个 大 的 版 本 库 拆 成 多 个 版 本 库 组 合 来 使 用 啊 。 而 且 我 还 有 稀 芒 检 出 的 
功能 ， 只 不 过 很 少 有 人 用 到 妆 了 。 


SVN: 我 能 添加 空 目 未， 你 好 像 不 能 吧 ? 


Git: 是 的 ， 我 现在 还 不 能 记录 空 目 未， 但 是 用 户 往往 在 空 目 未 下 
创建 一 个 隐 含 文件 ， 并 将 该 隐 含 文件 添加 到 版 本 库 中 ， 这 束 实 现 了 空 
目 孙 添加 的 功能 。 


[1| http://www.ossxp.com/doc/pysvnmanager/user-guide/user-guide.html 


C.2 ”Git 和 SVN 命 令 对 照 


svn-i/hostipath/to/repos git-/host/path/to/repos. git 
https://host/path/to/repos ssh:/user(mhost/pathito/repos. git 


URL file-///pathito/repos userfwhost-path/to/repos.git 


file:i/path/to/repos.git 


导入 数据 svn import <path> <url> -m ... git clone:; git add .: git commit 


版 本 库 检 出 svn checkout <url/of/trunk> <path> git clone <url> <path> 


版 本 库 分 支 检 出 svn checkout <url/of/branches/name> <path> git clonc -b <branch> <url> <path> 


( 续 ) 


更 新 至 最 新 提交 sv update -Fr HEAD git checkout master 


sin es 


切换 至 里 程 夏 syn Switch <url/ofitags/name> git checkout <tag> 


切换 至 分 支 syn switch <url/of/branches/name> git checkout <branch> 


清除 未 跟踪 文件 svn status | sed -ce "s/~Y/" | xargs rm git clean 
清除 工作 锁定 = 
获取 文件 历史 版 本 svn cat -r<rev> <url/of/file>(@<rev> > <output> git show <commit>:<path> > <output> 
反 删 除 文 件 syn cp -rerev> <urliofifile>(@<rev> <path> git add <path> 
git diff 
工作 区 差异 比较 svn diff Sit diff -cached 
git diff HEAD 
版 车 间 荔 异 比较 svn diff -r <revi>:<rev2> <path> git diff <commitl> <commit2> — <path> 
直 看 工作 区 状态 | smss | shss 
提交 svn commit -m "<msg>” Sit commit -a -m “<msg>" ; git push 
svn js <url/of/tags/> git tag 
显示 里 程 碑 /分 支 svn ls <url/of/branches/> git branch 
创建 里 程 碑 syn cp <url/ofitrunk/> <url/of/tags/name> pe 人 
币 除 里 程 砷 svn rm <urliofltags/namec> git tag -d <tagname> 
创建 分 支 syn cp <url/ofitrunk/> git branch <branch> <commit> 


<url/ofibranches/name> mit checkout -b <branch> <commit> 


猎 除 分 支 svn rm <urliof/branehes/name> git branch -d <branch> 


比较 项 目 


导出 项 目 文件 


反 转 提交 
提交 拣选 
分 支 合并 


冲突 解决 


显示 文件 列表 


更 改 提 交 说 明 
撤销 提交 


属性 


SVN 命令 


svn export -r <rev> <path> <output/path> 


svn cxport -r <rev> <url> <output/path> 


SVN merge -C -<rev> 


svn merge -Cc <rev> 


svn merge <url/of/ibranch> 


svn resolve --accept=<ARG> <path> 


svn resolved <path> 


svn ls 


svn ls <url> -r <rey> 


syn ps --reyprop -r<rev> svn:log "<msg>" 


svnadmin dump、svnadmin load 及 svndumpfiltcr 
svn-ignore 

syn:mime-type 

svn:col-style 

syn:externals 


svn:kcywords 


GIT 命令 
git archive -0 <output.tar> <commit> 


git archivye -0 <output.tar> 
—remote=<url> <commit> 


git revert <commit> 

git cherry-pick <commit> 
git merge <branch> 

git mergetool 

git add <path> 

git ls-files 

git ls-trec <commit> 

git commit --amend 

git resct [ -soft | --hard ] HEAD” 
.gitignore 文件 

tcxt 属性 

col 属性 

git submodule 命令 


export-subst 更 性 


附 隶 D Git 与 Hg 面对面 
D.1 面对面 访谈 采 


Git: 你 好 Hg， 我 发 现 我 们 真 的 很 像 。 


Hg: 是 啊 ， 人 们 把 我 们 都 归 类 为 分 布 式 版 本 控制 工具 ， 所 以 我 们 
之 间 的 相似 度 ， 要 比 和 CVS、SVN 的 相似 度 高 得 多 了 。 


Hg: 我 是 用 Python 和 人 少 部 分 的 C 语 言 实 现 的 ， 你 呢 ? 


Git: 我 的 核心 当然 是 使 用 C 语 言 了 ， 因 为 Linus Torvalds 最 爱 用 C 
语言 了 。 我 的 很 多 命令 还 使 用 了 Shell 脚 本 和 Perl 语 言 开 发 ，Python 用 的 
很 少 。 


Hg: 大 量 使 用 C 语 言 ， 是 你 的 性 能 比 我 高 的 原因 吗 ? 


Git: 当然 不 是 了 ， 你 不 也 在 核心 模块 使 用 C 语 言 了 么 ? 问题 的 关 
键 在 于 我 的 对 象 库 设 计 得 非常 优秀 。 你 不 要 起 了 我 是 谁 发 明 的 ， 那 可 
是 大 名 鼎鼎 的 Linux 之 父 Linus Torvalds 啊 ， 他 对 Linux 文 件 系统 可 是 再 
熟悉 不 过 的 了 ， 所 以 他 能 够 以 文件 系统 开发 者 的 视角 来 实现 我 的 核 
心 。 


Git: 还 有 我 的 网 络 传输 过 程 非常 直观 ， 可 以 显示 实时 的 进度 ， 好 
像 我 从 你 那里 没有 看 到 。 之 所 以 我 能 够 有 这 样 的 实现 ， 是 因为 我 使 用 
了 “智能 协议 ”。 在 网 络 传输 的 两 端 都 局 用 了 相应 的 辅助 程序 ， 实 现 差 
异 传输 及 传输 进度 的 计算 和 显示 。 


Hg: 实际 上 我 也 文 持 进度 显示 山 ， 不 过 是 通过 Progress 插 件 中 实 
现 的， 需要 通过 修改 配置 文件 启用 该 插件 。 


Hg: 我 有 一 个 特点 是 SVN 用 户 非 党 喜欢 的 ， 束 是 我 的 顺序 数字 版 
本 号 。 
Git: 你 的 顺序 数字 版 本 号 只 在 本 地 版 本 库 中 有 效 。 也 就 是 说 ， 你 


不 能 像 SVN 那 样 将 顺序 数字 版 本 号 作为 项 目 本 映 的 版 本 号 ， 因 为 换 成 
男 外 一 个 版 本 库 的 克隆 ， 那 个 数字 版 本 号 束 会 不 一 样 了 。 


Hg: 我 觉得 你 的 暂 存 区 (stage) 的 概念 太古 怪 了 。 我 提交 的 时 
候 ， 改 动 的 文件 会 直接 提交 而 不 需要 进行 什么 注册 到 暂 存 区 的 操作 。 


Git: 让 读者 来 做 评判 吧 。 如 采 读 者 读 过 本 书 的 第 2 篇 ， 一 定 会 说 
Git 的 暂 存 区 帅 用 了。 


Hg: 我 只 允许 用 户 对 最 近 的 一 次 提交 进行 回 深 撤 销 ， 而 你 (Git 
择 么 能 允许 用 户 撤销 


任意 多 次 历史 提交 呢 ? 那样 安全 吗 ? 


Git: 这 就 是 我 的 对 象 库 和 引用 设计 的 强大 之 处 ， 我 可 以 使 用 git 
reset 命 令 将 工作 分 文 进行 任意 的 重 置 ， 丢 弃 任意 多 的 历史 。 至 于 安全 
性 ， 我 的 重 置 命令 有 一 个 保险 : reflog， 我 随时 可 以 参照 reflog 的 记录 
来 弥补 错误 的 重 置 。 


Hg: 我 们 的 revert 命 令 好 像 不 同 ? 


Git， 你 Hg 的 hg revert 命 令 和 SVN 的 svn revert 命 令 相似 ， 是 取消 本 
地 修改 ， 用 原始 拷贝 柳 震 。 你 的 这 个 操作 在 我 这 里 是 用 git checkout 命 
令 来 实现 的 。 我 也 有 一 个 git revert 命 令 ， 但 是 这 个 命令 是 针对 某 个 历 
史 提 交 进 行 的 反 向 操作 ， 以 取消 该 历史 提交 的 改动 。 


Hg: 我 执行 日 志 查 看 能 够 看 到 文本 显示 的 分 文 图 ， 你 昵 ? 


Git: 我 需要 在 日 志 显 示 时 添加 参数 ， 即 使 用 命令 git log--graph 。 
我 文 持 通过 建立 别名 来 实现 简洁 的 调用 ， 例 如 建立 一 个 名 为 glog 的 别 
名 O 


Git: 我 听 说 你 Hg 不 文 持 分 文 ? 


Hg: 你 说 的 是 昨天 的 我 ， 现 在 有 了 Bookmarks 插 件 中 ， 我 也 拥有 
和 你 类 似 的 分 文 实现 。 不 过 传统 来 讲 我 还 是 以 克隆 来 实现 分 文 的 。 


Git: 实际 上 我 的 每 一 个 克隆 的 版 本 库 也 相当 于 独立 的 分 文 ， 但 是 
因为 我 有 强大 的 分 文 功 能 ， 因 此 很 多 用 户 还 没有 意识 到 。 使 用 Topgit 


的 用 户 就 应 该 使 用 版 本 库 克 隆 作 为 Topgit 本 身 的 分 支管 理 。 


Git: 还 有 ， 因 为 我 对 分 文 的 完整 文 持 ， 使 得 我 可 以 和 SVN 很 好 地 
协同 工作 。 我 可 以 将 整个 SVN 转 换 为 本 地 的 Git 库 ， 但 是 你 Hg， 显 然 只 
能 每 次 转换 一 个 分 文 。 


Hg: 是 的 ， 我 要 辣 你 多 学 习 。 


[1] 感谢 来 自 中 国 台 湾 的 Willie Wu 对 我 博客 的 评论 。 
[2| http://mercurial.selenic.com/wiki/ProgressExtension 


[3] http://mercurial.selenic.com/wiki/BookmarksExtension 


D.2 ”Git 和 Hg 命令 对 照 


http:Whostbpathytoyrepos git-//hostipath/to/repos.sit 


ssh://user(w host/path/to/repos ssh:/usecrdhost/pathito/repos. git 


URL file:/Wpathitoirepos uscriahost:path/to/repos.git 


[oj [uscr] 
配置 username = Firstname Lastname <maill@ name = Pirstname Lastname 
addr> email = maill@addr 


比较 项 目 
版 本 库 初 始 化 
版 本 库 克 降 
获取 也 本 库 更 新 
更 新 至 历史 版 本 
更 新 到 指定 日 期 
更 新 至 最 新 提交 
切换 至 里 程 凰 
切换 至 分 支 


还 原文 件 / 强制 覆盖 


添加 文件 
删除 文件 
添加 及 删除 文件 
移动 文件 


撤销 评 加 、 秋 除 等 操作 


清除 未 跟踪 文件 
获取 文件 历史 版 本 
反 删 除 文件 


工作 区 差异 比较 


版 本 间 差 异 比 较 
查看 工作 区 状态 
检 交 

推进 提交 


显示 提交 日 志 


逐 行 追 油 


显示 里 程 碑 / 分 支 


〈 续 ) 


HG 命令 GIT 命令 


hg init <path> git init [--barc] <path> 
hg clone <url> <path> git clone <url> <path> 
hs puil --update git pull 
hg update -r <rev> git checkout <commit> 
hg updatc -d <date> git checkout HEAD(@"!<date>}' 


hg updatc git checkout master 


hg update -r <tag> git checkout <tag> 


hg update -r <branch> git checkout <branch> 


hg update -C <path> git checkout -- <path> 


hg add <path> git add <path> 
hg rm <path> git rm <path> 
hg addremove git add -A 


hg my <old> <new> 


git mv <old> <new> 
hg revert <path> git resct -- <path> 


hg cican git clcan -fd 


hg cat -r<rev> <path> > <output> 


git show <commit>:<path> > <output> 
hg add <path> git add <path> 
git diff 

git diff --cached 
git dF HEAD 
hg diff -r <revl> -r <rev2> <path> git diff <commitl> <commit2> -- <path> 


git status -s 


git commit -a -mt "<msg>" 


hs commit -m "<msg>" 


git push 
git log 
hs glog | less git log --graph 


hg annotatc git annotate, git blame 


hs tags git tag 

hg branches 

hg bookmarks git branch 
git show-ref 


《 续 ) 
比较 项 目 HG 命令 GIT 命令 


创建 请 程 砷 hg tag [-m "<msg>"] [-r =rev=] <tagname> git tag [-m "<msg>"] <tagname> [<commit>] 


出 除 理 程 砷 hg tag --remove <tagname> git tag -d <tagname> 


hg branch <branch> git branch <branch> <commit> 


创建 分 支 Y 
hg bookmark <branch> git checkout -b <branch> <commit> 
a hg commit --closc-branch > 
制 除 分 支 he Dol ain git branch -d <branch: 
git archive -oe <output-tar> <commit> 
导出 项 目 文件 VOIP git archive -o <output.tar> --remote=<url> 
=commit> 
反 转 提交 hg backout <rev> git revert <commit> 
hg resolve --tool=<tool> git mergctool 
冲突 解决 
hg resolve -m <path> git add <path> 
撤 锌 多 次 提交 Hg + MQ git reset [ --soft | --hard ] HEAD~<n> 
撤销 历史 棍 交 Hg + MO git rebase -i <commit>” 
.hgignore 文件 -gitignore 文件 
pager 扩展 内 置 分 页 器 
color 扩 展 color.* 配置 变量 
杂项 
graphlog 扩展 git log --graph 
hgk 扩展 gitk 


